On Tue, Oct 7, 2014 at 8:33 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > On 7 October 2014 03:31, Peter Geoghegan <p...@heroku.com> wrote: >>> It may be that people on reading this now believe Peter's HW locking >>> approach is the best. I'm happy to go with consensus. >> >> I bet you didn't think that you'd say that a week ago. :-) > > You're right, because last week I thought heavyweight locking sucks > and I still think that; I haven't said it is the best. > > What we've just discovered is that we're locking 100% of the time, but > its not needed in 99.9% of cases and is arguable in the 0.1% case - > not "required" at all. > > The price of avoiding that rare and possibly erroneous condition seems > high to me. > > Is there a way of detecting that we are updating a unique constraint > column and then applying the HW locking only in that case? Or can we > only apply locking when we have multiple unique constraints on a > table? > If so, I would withdraw any objection to the HW locking technique.
I'm not up on the details of what Peter's patch does with heavyweight locking, but I'd say it this way: if the patch uses heavyweight locking routinely, that's probably not going to scale well[1]. If the patch detects possible conflicts and uses heavyweight locking only in those cases and for the specific purpose of untangling those conflicts, then that might well be OK. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company [1] As evidence, I offer the fact that removing 1 of 2 places where heavyweight locking is used in hash indexes resulted in a large performance gain at high client counts. See commit 76837c1507cb5a5a0048046233568447729e66dd. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
