Re: postgresql latency & bgwriter not doing its job - Mailing list pgsql-hackers

From Robert Haas
Subject Re: postgresql latency & bgwriter not doing its job
Date
Msg-id CA+TgmoY6uq=bphJeFDrNZUsqtYHr5t0GAR=RefWE3v9Cj_8G1g@mail.gmail.com
Whole thread Raw
In response to Re: postgresql latency & bgwriter not doing its job  (Ants Aasma <ants@cybertec.at>)
Responses Re: postgresql latency & bgwriter not doing its job  (didier <did447@gmail.com>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: PQputCopyEnd doesn't adhere to its API contract
Next
From: Joel Jacobson
Date:
Subject: Re: PL/pgSQL 1.2