Re: postgresql latency & bgwriter not doing its job

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: didier <did447(at)gmail(dot)com>
Cc: Ants Aasma <ants(at)cybertec(dot)at>, Andres Freund <andres(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Claudio Freire <klaussfreire(at)gmail(dot)com>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: postgresql latency & bgwriter not doing its job
Date: 2014-09-05 18:09:39
Message-ID: CA+Tgmoa-C9fhAM9VynczXqhYmH40t6kBzid7hkbr_ZBrSQXn5A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 5, 2014 at 4:17 AM, didier <did447(at)gmail(dot)com> wrote:
>> It's not the size of the array that's the problem; it's the size of
>> the detonation when the allocation fails.
>>
> You can use a file backed memory array
> Or because it's only a hint and
> - keys are in buffers (BufferTag), right?
> - transition is only from 'data I care to data I don't care' if a
> buffer is concurrently evicted when sorting.
>
> Use a pre allocate buffer index array an read keys from buffers when
> sorting, without memory barrier, spinlocks, whatever.

If by a file-backed memory array you mean mmap() something, that
doesn't do anything to address the possibility of failure. mmap(),
like malloc(), can fail.

But I think we don't really need to have this argument. Andres's
proposal to put this in the main shared memory segment sounds fine to
me. If allocating that fails, you'll know to reduce shared_buffers
and try again. If it succeeds, you should be safe after that.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Claudio Freire 2014-09-05 19:18:47 Re: postgresql latency & bgwriter not doing its job
Previous Message Merlin Moncure 2014-09-05 16:37:27 Re: PL/pgSQL 2