Pierre C wrote:
Actually, I meant that in the case of a seq scan, PG will try to use just a few buffers (a ring) in shared_buffers instead of thrashing the whole buffers. But if there was actually a lot of free space in shared_buffers, do the pages stay, or do they not ?
Pages inserted into the ring buffer and later re-used for new data do not stay behind even if there is room for them. There's a potential improvement possible in that code involving better management of the situation where the buffer cache hasn't actually reached full capacity yet, but as it's an unusual case it's hard to justify optimizing for. Besides, the hope is that in this case the OS cache will end up caching everything anyway until it has a reason to evict it. So if you follow the rest of the data suggesting you should not give all the memory to PostgreSQL to manage, you end up with a reasonable solution to this problem anyway. Those pages will just live in the OS cache instead of the database's, with only a few trickling in and staying behind each time you do a sequential scan.
-- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@xxxxxxxxxxxxxxx www.2ndQuadrant.us -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
