Re: commit_delay, siblings

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: commit_delay, siblings
Дата
Msg-id 8973.1120054562@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: commit_delay, siblings  (Simon Riggs <simon@2ndquadrant.com>)
Ответы Re: commit_delay, siblings  (Simon Riggs <simon@2ndquadrant.com>)
Re: commit_delay, siblings  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Список pgsql-hackers
Simon Riggs <simon@2ndquadrant.com> writes:
> Group commit is a well-documented technique for improving performance,

The issue here is not "is group commit a good idea in the abstract?".
It is "is the commit_delay implementation of the idea worth a dime?"
... and the evidence we have all points to the answer "NO".  We should
not let theoretical arguments blind us to this.

I posted an analysis some time ago showing that under heavy load,
we already have the effect of ganged commits, without commit_delay:
http://archives.postgresql.org/pgsql-hackers/2002-10/msg00331.php

It's likely that there is more we can and should do, but that doesn't
mean that commit_delay is the right answer.  commit_delay doesn't do
anything to encourage ganging of writes, it just inserts an arbitrary
delay that's not synchronized to anything, and is probably an order
of magnitude too large anyway on most platforms.

> I would ask that we hold off on their execution, at least for the
> complete 8.1 beta performance test cycle.

I'm willing to wait a week while Tatsuo runs some fresh tests.  I'm
not willing to wait indefinitely for evidence that I'm privately
certain will not be forthcoming.
        regards, tom lane


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

Предыдущее
От: Hannu Krosing
Дата:
Сообщение: Re: Implementing SQL/PSM for PG 8.2 - debugger
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Startup successful message, even on failure