Re: commit_delay, siblings

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: commit_delay, siblings
Дата
Msg-id 1120029276.3667.52.camel@localhost.localdomain
обсуждение исходный текст
Ответ на Re: commit_delay, siblings  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: commit_delay, siblings  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: commit_delay, siblings  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: commit_delay, siblings  (Kenneth Marshall <ktm@it.is.rice.edu>)
Список pgsql-hackers
On Wed, 2005-06-22 at 11:11 -0700, Josh Berkus wrote: 
> Hans, Tom,
> 
> > We have done extensive testing some time ago.
> > We could not see any difference on any platform we have tested (AIX,
> > Linux, Solaris). I don't think that there is one at all - at least not
> > on common systems.
> 
> Keen then.  Any objections to removing the GUC?   We desperately need means 
> to cut down on GUC options.

Group commit is a well-documented technique for improving performance,
but the gains only show themselves on very busy systems. It is possible
in earlier testing any apparent value was actually hidden by the
BufMgrLock issues we have now resolved in 8.1. We now see XLogInsert as
being very nearly the highest routine on the oprofile. That tells me
that it could now be time for group commit to show us some value, if any
exists.

DB2 and Berkeley-DB use group commit, while other rdbms use log writer
processes which effectively provide the same thing. It would surprise me
if we were unable to make use of such a technique, and worry me too.

I would ask that we hold off on their execution, at least for the
complete 8.1 beta performance test cycle. We may yet see gains albeit,
as Tom points out, that benefit may only be possible on only some
platforms.

Best Regards, Simon Riggs



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

Предыдущее
От: Michael Glaesemann
Дата:
Сообщение: Startup successful message, even on failure
Следующее
От: Teodor Sigaev
Дата:
Сообщение: Re: GiST concurrency commited