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 по дате отправления: