On 3/19/09 10:37 AM, "Bruce Momjian" <bruce@xxxxxxxxxx> wrote: > 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. Of course. The proposal was to leave it at the default, and obviously document that it is not likely to be used. Its 1000x safer than fsync=off . . . > > -- > 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
