On Tue, Apr 12, 2016 at 2:38 PM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
