Re: postgresql latency & bgwriter not doing its job

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: postgresql latency & bgwriter not doing its job
Дата
Msg-id CA+TgmoY6uq=bphJeFDrNZUsqtYHr5t0GAR=RefWE3v9Cj_8G1g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: postgresql latency & bgwriter not doing its job  (Ants Aasma <ants@cybertec.at>)
Ответы Re: postgresql latency & bgwriter not doing its job  (didier <did447@gmail.com>)
Список pgsql-hackers
On Thu, Sep 4, 2014 at 3:09 AM, Ants Aasma <ants@cybertec.at> wrote:
> On Thu, Sep 4, 2014 at 12:36 AM, Andres Freund <andres@2ndquadrant.com> wrote:
>> It's imo quite clearly better to keep it allocated. For one after
>> postmaster started the checkpointer successfully you don't need to be
>> worried about later failures to allocate memory if you allocate it once
>> (unless the checkpointer FATALs out which should be exceedingly rare -
>> we're catching ERRORs). It's much much more likely to succeed
>> initially. Secondly it's not like there's really that much time where no
>> checkpointer isn't running.
>
> In principle you could do the sort with the full sized array and then
> compress it to a list of buffer IDs that need to be written out. This
> way most of the time you only need a small array and the large array
> is only needed for a fraction of a second.

It's not the size of the array that's the problem; it's the size of
the detonation when the allocation fails.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: PQputCopyEnd doesn't adhere to its API contract
Следующее
От: Joel Jacobson
Дата:
Сообщение: Re: PL/pgSQL 1.2