Re: reducing the overhead of frequent table locks - now, with WIP patch
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Christopher Browne <cbbrowne@gmail.com>
Cc: Simon Riggs <simon@2ndquadrant.com>, Kevin Grittner <Kevin.Grittner@wicourts.gov>, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2011-06-06T20:04:08Z
Lists: pgsql-hackers
On Mon, Jun 6, 2011 at 3:59 PM, Christopher Browne <cbbrowne@gmail.com> wrote: > On Mon, Jun 6, 2011 at 5:13 PM, Simon Riggs <simon@2ndquadrant.com> wrote: >> The cost to us is a few days work and the benefit is a whole year's >> worth of increased performance for our user base, which has a hardware >> equivalent well into the millions of dollars. > > I doubt that this is an accurate reflection of the cost. > > What was presented by Robert Haas was a "proof of concept," and he > pointed out that it had numerous problems. To requote: > > "There are numerous problems with the code as it stands at this point. > It crashes if you try to use 2PC, which means the regression tests > fail; it probably does horrible things if you run out of shared > memory; pg_locks knows nothing about the new mechanism (arguably, we > could leave it that way: only locks that can't possibly be conflicting > with anything can be taken using this mechanism, but it would be nice > to fix, I think); and there are likely some other gotchas as well." The latest version of the patch is in much better shape: http://archives.postgresql.org/pgsql-hackers/2011-06/msg00403.php But this is not intended as disparagement for the balance of your argument. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company