Re: Proposal of tunable fix for scalability of 8.4

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Proposal of tunable fix for scalability of 8.4
Дата
Msg-id 200903192327.n2JNRGl10644@momjian.us
обсуждение исходный текст
Ответ на Re: Proposal of tunable fix for scalability of 8.4  (Scott Carey <scott@richrelevance.com>)
Список pgsql-performance
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. +

В списке pgsql-performance по дате отправления:

Предыдущее
От: "Jignesh K. Shah"
Дата:
Сообщение: Re: Proposal of tunable fix for scalability of 8.4
Следующее
От: "Jignesh K. Shah"
Дата:
Сообщение: Re: Postgres benchmarking with pgbench