From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | didier <did447(at)gmail(dot)com>, 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>, 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 19:18:47 |
Message-ID: | CAGTBQpYfD6-vtj=Nni4NnDz_6qGoCR6KOWkkPJCovepivkMphg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Sep 5, 2014 at 3:09 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> 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.
It's worse. If your process needs to page from disk when touching a
byte in the mmap'd array, and the disk somehow fails to work, you get
a segmentation fault.
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2014-09-05 19:23:58 | Re: bad estimation together with large work_mem generates terrible slow hash joins |
Previous Message | Robert Haas | 2014-09-05 18:09:39 | Re: postgresql latency & bgwriter not doing its job |