| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
| Cc: | Andres Freund <andres(at)2ndQuadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Claudio Freire <klaussfreire(at)gmail(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers |
| Date: | 2014-05-07 14:07:07 |
| Message-ID: | 26663.1399471627@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> I think I'm arguing myself towards using a BufferAccessStrategy of
> BAS_BULKREAD for large IndexScans, BitMapIndexScans and
> BitMapHeapScans.
As soon as you've got some hard evidence to present in favor of such
changes, we can discuss it. I've got other things to do besides
hypothesize.
In the meantime, it seems like there is an emerging consensus that nobody
much likes the existing auto-tuning behavior for effective_cache_size,
and that we should revert that in favor of just increasing the fixed
default value significantly. I see no problem with a value of say 4GB;
that's very unlikely to be worse than the pre-9.4 default (128MB) on any
modern machine.
Votes for or against?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Merlin Moncure | 2014-05-07 14:10:29 | Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers |
| Previous Message | Simon Riggs | 2014-05-07 13:50:41 | Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers |