Re: Redesigning checkpoint_segments

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: Redesigning checkpoint_segments
Дата
Msg-id 1370634366.21685.YahooMailNeo@web162903.mail.bf1.yahoo.com
обсуждение исходный текст
Ответ на Re: Redesigning checkpoint_segments  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> wrote:
> Kevin Grittner <kgrittn@ymail.com> wrote:

>> One such surprise was that the conversion ran faster, even on a
>> "largish" database of around 200GB, with 3 checkpoint_segments
>> than with larger settings.
>
> !
>
> I can't account for that finding, because my experience is that
> small checkpoint_segments settings lead to *terrible* bulk
> restore performance.
>
> *scratches head*

Perhaps it was due to some of the "running with scissors" settings
we used for the upgrade process that we don't normally use, like
fsync = off and full_page_writes = off.  We also used a larger than
usual maintenance_work_mem which reduced disk sorts, possibly
helping the WAL files to remain cached on the controller.

Maybe it also helped keep data flowing to the actual disks, so that
it didn't alternate between "idle" and "glutted" states, although I
don't have any evidence to support that theory.

--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Avoiding bloat in the presence of a long-running transaction (Re: Freezing without write I/O)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Bad error message on valuntil