Re: Why do we still have commit_delay and commit_siblings?

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Why do we still have commit_delay and commit_siblings?
Дата
Msg-id CA+TgmoZbbmxVCJrRmttPs1aPr9Q9wTXQDYcmaSaZD=QvcaWR6A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Why do we still have commit_delay and commit_siblings?  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
On Tue, May 15, 2012 at 11:05 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> My comments were appropriate: if I tried to suggest we add
> commit_delay as a feature, it would be rejected and rightly so.

Fair point.

> Some
> caution in its removal is appropriate, but since we've been discussing
> it since before your first post to hackers, probably even before mine,
> I figure that is way past long enough.
>
> I beg you to prove me wrong and demonstrate the value of commit_delay,
> since we will all benefit from that.

Interestingly, we seem to have had this same argument 7 years ago,
with different participants.

http://archives.postgresql.org/pgsql-hackers/2005-06/msg01463.php

What's really bothering me here is that a LOT has changed in 9.2.
Besides the LWLockAcquireOrWait stuff, which improves fsync
scalability quite a bit, we have also whacked around the WAL writer
behavior somewhat.  It's not necessarily the case that things which
didn't work well before still won't work well now.  On the other hand,
I'll grant you that our current implementation of commit_delay is
pretty boneheaded.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: Why do we still have commit_delay and commit_siblings?
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Bug in to_tsquery(), and fix