Re: Backport of fsync queue compaction
От | Robert Haas |
---|---|
Тема | Re: Backport of fsync queue compaction |
Дата | |
Msg-id | CA+TgmobRk=wb3zSuj7-QPSuNQ+JnM4NB4neR2uB9+fnWDmWsyQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Backport of fsync queue compaction (Greg Smith <greg@2ndQuadrant.com>) |
Ответы |
Re: Backport of fsync queue compaction
Re: Backport of fsync queue compaction Re: Backport of fsync queue compaction Re: Backport of fsync queue compaction |
Список | pgsql-hackers |
On Tue, Jun 19, 2012 at 5:33 PM, Greg Smith <greg@2ndquadrant.com> wrote: > In January of 2011 Robert committed 7f242d880b5b5d9642675517466d31373961cf98 > to try and compact the fsync queue when clients find it full. There's no > visible behavior change, just a substantial performance boost possible in > the rare but extremely bad situations where the background writer stops > doing fsync absorption. I've been running that in production at multiple > locations since practically the day it hit this mailing list, with backports > all the way to 8.3 being common (and straightforward to construct). I've > never seen a hint of a problem with this new code. I've been in favor of back-porting this for a while, so you'll get no argument from me. Anyone disagree? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: