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
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? |