Re: commit_delay, siblings
От | Michael Paesold |
---|---|
Тема | Re: commit_delay, siblings |
Дата | |
Msg-id | 031701c57c89$b4cc5160$0f01a8c0@zaphod обсуждение исходный текст |
Ответ на | commit_delay, siblings (Josh Berkus <josh@agliodbs.com>) |
Список | pgsql-hackers |
Simon Riggs wrote: > Group commit is a well-documented technique for improving performance, > but the gains only show themselves on very busy systems. It is possible > in earlier testing any apparent value was actually hidden by the > BufMgrLock issues we have now resolved in 8.1. We now see XLogInsert as > being very nearly the highest routine on the oprofile. That tells me > that it could now be time for group commit to show us some value, if any > exists. > > DB2 and Berkeley-DB use group commit, while other rdbms use log writer > processes which effectively provide the same thing. It would surprise me > if we were unable to make use of such a technique, and worry me too. > > I would ask that we hold off on their execution, at least for the > complete 8.1 beta performance test cycle. We may yet see gains albeit, > as Tom points out, that benefit may only be possible on only some > platforms. I don't remember the details exactly, but isn't it so that postgres has some kind of group commits even without the commit_delay option? I.e. when several backends are waiting for commit concurrently, the one to get to commit will actually commit wal for all waiting transactions to disk? I remember the term "ganged wal writes" or something similar. Tom, can you elaborate on this? Please tell me if I am totally off track. ;-) Best Regards, Michael Paesold
В списке pgsql-hackers по дате отправления: