Re: commit_delay, siblings
От | Bruce Momjian |
---|---|
Тема | Re: commit_delay, siblings |
Дата | |
Msg-id | 200506291203.j5TC3J202105@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: commit_delay, siblings (Simon Riggs <simon@2ndquadrant.com>) |
Список | pgsql-hackers |
Simon Riggs wrote: > On Wed, 2005-06-22 at 11:11 -0700, Josh Berkus wrote: > > Hans, Tom, > > > > > We have done extensive testing some time ago. > > > We could not see any difference on any platform we have tested (AIX, > > > Linux, Solaris). I don't think that there is one at all - at least not > > > on common systems. > > > > Keen then. Any objections to removing the GUC? We desperately need means > > to cut down on GUC options. > > 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. Interesting. I didn't know other databases used group commits. Your idea of keeping it for the 8.1 testing cycle has merit. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
В списке pgsql-hackers по дате отправления: