Обсуждение: proposal: adding a GUC for BAS_BULKREAD strategy

Поиск
Список
Период
Сортировка

proposal: adding a GUC for BAS_BULKREAD strategy

От
didier
Дата:
Hi,

Currently the value is hard code to NBuffers / 4 but ISTM that with
bigger shared_buffer it's too much, ie even with a DB 10 to 20 time
the memory size there's a lot of tables under this limit and nightly
batch reports are trashing the shared buffers cache as if there's no
tomorrow.


regards,



Re: proposal: adding a GUC for BAS_BULKREAD strategy

От
Andres Freund
Дата:
Hi,

On 2014-09-23 14:47:33 +0200, didier wrote:
> Currently the value is hard code to NBuffers / 4 but ISTM that with
> bigger shared_buffer it's too much, ie even with a DB 10 to 20 time
> the memory size there's a lot of tables under this limit and nightly
> batch reports are trashing the shared buffers cache as if there's no
> tomorrow.

I'd like the ability to tune this as well. Even though I more often want
to entirely disable it, rather than make it more aggressive. For
workloads where the majority of the read data fits into shared_buffers
and sequential scans over large relations are something happening
frequently, the current strategy *sucks* because the large table will
pretty much never get cached.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services