On Wed, Oct 1, 2014 at 4:23 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > Quoting general research and other points about value locking are > reasonable in the general section, but not in the description for 1.
I also made a similar comparison of #3. I don't think that reflects a bias. > I'm glad you've called the first option "Heavyweight Page Locking". > That name sums up what I see as the major objection to it, which is > that performance and scalability of the whole server will be damaged > signiciantly by using heavyweight locks for each row inserted. Please > add that concern as a negative; I'm sure testing has been done, but > not comparative testing against other techniques. Comparative testing against both other techniques (#1, at a time when #1 and #2 were otherwise comparable), and plain inserts and updates has shown the performance to be very good. The evidence suggests that using a heavyweight lock like this is fine. Don't promise tuples use heavyweight locks? The coarser granularity did not appear to be significant once we optimize retries to avoid hwlocking. #1 came out a bit ahead of #2. So maybe the bloat of #2 is almost, but not quite, cancelled out by the hwlocking coarseness. But then, I specifically stated that it seemed that not having bloating was not much of an advantage for #1. We're going to have a benchmark between #1 and #2 when #2 is properly integrated with the rest of the updated patch (just because we can). #1 is the fastest of #1 and #2 last I checked, but there wasn't all that much in it. > I am motivated to > explain the promise index tuple approach further because of this, > which is an optimistic approach to locking. > The stated disadvantages for 3 are not accurate, to put it mildly. Honestly, how could I know what they are? The explanation I heard from you and Andres has been very short on details. The points for #3 are *my* concerns. I had to start somewhere. I'll consider your rebuttal to those points that you make on a new thread separately. > But that's been useful because what was a small thought experiment is > beginning to look like a useful approach. I will post a summary of my > understanding. Thanks. Actually, this wiki page will probably pay for itself just by allowing us to refer to #1, #2, and #3. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
