Re: Proposal of tunable fix for scalability of 8.4

Scott Carey wrote:
> On 3/19/09 10:37 AM, "Bruce Momjian" <bruce@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  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +