Re: Why do we still have commit_delay and commit_siblings?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Peter Geoghegan <peter(at)2ndquadrant(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Why do we still have commit_delay and commit_siblings?
Date: 2012-05-15 16:09:42
Message-ID: CA+TgmoZbbmxVCJrRmttPs1aPr9Q9wTXQDYcmaSaZD=QvcaWR6A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 15, 2012 at 11:05 AM, Simon Riggs <simon(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2012-05-15 16:22:42 Bug in to_tsquery(), and fix
Previous Message Jeff Janes 2012-05-15 16:07:07 Re: Why do we still have commit_delay and commit_siblings?