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