On Tue, Apr 12, 2016 at 11:38 AM, Andres Freund <andres@anarazel.de> wrote:
>> And, on the other hand, if we don't do something like that, it will be
>> quite an exceptional case to find anything on the free list. Doing it
>> just to speed up developer benchmarking runs seems like the wrong
>> idea.
>
> I don't think it's just developer benchmarks. I've seen a number of
> customer systems where significant portions of shared buffers were
> unused due to this.
>
> Unless you have an OLTP system, you can right now easily end up in a
> situation where, after a restart, you'll never fill shared_buffers.
> Just because sequential scans for OLAP and COPY use ringbuffers. It sure
> isn't perfect to address the problem while there's free space in s_b,
> but it sure is better than to just continue to have significant portions
> of s_b unused.
I agree that the ringbuffer heuristics are rather unhelpful in many
real-world scenarios. This is definitely a real problem that we should
try to solve soon.
An adaptive strategy based on actual cache pressure in the recent past
would be better. Maybe that would be as simple as not using a
ringbuffer based on simply not having used up all of shared_buffers
yet. That might not be good enough, but it would probably still be
better than what we have.
Separately, I agree that 256KB is way too low for VACUUM these days.
There is a comment in the buffer directory README about that being
"small enough to fit in L2 cache". I'm pretty sure that that's still
true at least one time over with the latest Raspberry Pi model, so it
should be revisited.
--
Peter Geoghegan