Re: postgresql latency & bgwriter not doing its job

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: postgresql latency & bgwriter not doing its job
Дата
Msg-id CA+Tgmoa-C9fhAM9VynczXqhYmH40t6kBzid7hkbr_ZBrSQXn5A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: postgresql latency & bgwriter not doing its job  (didier <did447@gmail.com>)
Ответы Re: postgresql latency & bgwriter not doing its job  (Claudio Freire <klaussfreire@gmail.com>)
Список pgsql-hackers
On Fri, Sep 5, 2014 at 4:17 AM, didier <did447@gmail.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



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

Предыдущее
От: Merlin Moncure
Дата:
Сообщение: Re: PL/pgSQL 2
Следующее
От: Claudio Freire
Дата:
Сообщение: Re: postgresql latency & bgwriter not doing its job