Re: Detrimental performance impact of ringbuffers on performance

On Tue, Apr 12, 2016 at 2:38 PM, 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.

You will eventually, because each scan will pick a new ring buffer,
and gradually more and more of the relation will get cached.  But it
can take a while.

I'd be more inclined to try to fix this by prewarming the buffers that
were in shared_buffers at shutdown.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company