Robert Haas wrote: > > The original poster's request is for a config parameter, for experimentation > > and testing by the brave. My own request was for that version of the lock to > > prevent possible starvation but improve performance by unlocking all shared > > at once, then doing all exclusives one at a time next, etc. > > That doesn't prevent starvation in general, although it will for some workloads. > > Anyway, it seems rather pointless to add a config parameter that isn't > at all safe, and adds overhead to a critical part of the system for > people who don't use it. After all, if you find that it helps, what > are you going to do? Turn it on in production? I just don't see how > this is any good other than as a thought-experiment. We prefer things to be auto-tuned, and if not, it should be clear how/when to set the configuration parameter. -- Bruce Momjian <bruce@xxxxxxxxxx> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
