Scott Carey wrote: > On 3/19/09 10:37 AM, "Bruce Momjian" <br...@momjian.us> 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 .
Right, but even if people don't use it, people tuning their systems have to understand the setting to know if they should use it, so there is a cost even if a parameter is never used by anyone. -- Bruce Momjian <br...@momjian.us> 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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
