proposal: adding a GUC for BAS_BULKREAD strategy

Started by didierover 11 years ago2 messages
#1didier
did447@gmail.com

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,

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

#2Andres Freund
andres@2ndquadrant.com
In reply to: didier (#1)
Re: proposal: adding a GUC for BAS_BULKREAD strategy

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers