Re: proposal: adding a GUC for BAS_BULKREAD strategy
| От | Andres Freund |
|---|---|
| Тема | Re: proposal: adding a GUC for BAS_BULKREAD strategy |
| Дата | |
| Msg-id | 20140923125552.GA3604@alap3.anarazel.de обсуждение |
| Ответ на | proposal: adding a GUC for BAS_BULKREAD strategy (didier <did447@gmail.com>) |
| Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: