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  (Christopher Browne <cbbrowne@gmail.com>)
Re: Backport of fsync queue compaction  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: Backport of fsync queue compaction  (Andres Freund <andres@2ndquadrant.com>)
Re: Backport of fsync queue compaction  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: [PATCH 10/16] Introduce the concept that wal has a 'origin' node
Следующее
От: Tom Lane
Дата:
Сообщение: Re: use of int4/int32 in C code