Re: Group Commit

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Group Commit
Дата
Msg-id 200704100104.l3A147x16083@momjian.us
обсуждение исходный текст
Ответ на Re: Group Commit  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Group Commit  (Greg Smith <gsmith@gregsmith.com>)
Re: Group Commit  ("Zeugswetter Andreas ADI SD" <ZeugswetterA@spardat.at>)
Список pgsql-hackers
Tom Lane wrote:
> Heikki Linnakangas <heikki@enterprisedb.com> writes:
> > I've been working on the patch to enhance our group commit behavior. The 
> > patch is a dirty hack at the moment, but I'm settled on the algorithm 
> > I'm going to use and I know the issues involved.
> 
> One question that just came to mind is whether Simon's no-commit-wait
> patch doesn't fundamentally alter the context of discussion for this.
> Aside from the prospect that people won't really care about group commit
> if they can just use the periodic-WAL-sync approach, ISTM that one way
> to get group commit is to just make everybody wait for the dedicated
> WAL writer to write their commit record.  With a sufficiently short
> delay between write/fsync attempts in the background process, won't
> that net out at about the same place as a complicated group-commit
> patch?

This is a good point.  commit_delay was designed to allow multiple
transactions to fsync with a single fsync.  no-commit-wait is going to
do this much more effectively (the client doesn't have to wait for the
other transations).  The one thing commit_delay gives us that
no-commit-wait does not is the guarantee that a commit returned to the
client is on disk, without any milliseconds delay.

The big question is who is going to care about the milliseconds delay
and is using a configuration that is going to benefit from commit_delay.
Basically, commit_delay always had a very limited use-case, but now
with no-commit-wait, commit_delay has an even smaller use-case.

I think the big question is whether commit_delay is ever going to be
generally useful.

I tried to find out what release commit_delay was added, and remembered
that the feature was so questionable we did not mention its addition in
the 7.1 release notes.  After six years, we are still unsure about the
feature.  Another big question is whether commit_delay is _ever_ going
to be useful, and with no-commit-wait being added, commit_delay looks
even more questionable and perhaps it should just be removed in 8.3.

--  Bruce Momjian  <bruce@momjian.us>          http://momjian.us EnterpriseDB
http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


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

Предыдущее
От: Gavin Sherry
Дата:
Сообщение: Re: Adjusting index special storage for pg_filedump's convenience
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Adjusting index special storage for pg_filedump's convenience