Re: Why do we still have commit_delay and commit_siblings? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Why do we still have commit_delay and commit_siblings?
Date
Msg-id CA+TgmoZbbmxVCJrRmttPs1aPr9Q9wTXQDYcmaSaZD=QvcaWR6A@mail.gmail.com
Whole thread Raw
In response to Re: Why do we still have commit_delay and commit_siblings?  (Simon Riggs <simon@2ndQuadrant.com>)
List 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 by date:

Previous
From: Jeff Janes
Date:
Subject: Re: Why do we still have commit_delay and commit_siblings?
Next
From: Heikki Linnakangas
Date:
Subject: Bug in to_tsquery(), and fix