> > > > What is the procedure that postgres uses to decide whether or not a > > table/index block will be left in the shared_buffers cache at the end > > of the operation? > > > > The only special cases are for sequential scans and VACUUM, which use continuously re-use a small section of the buffer cache in some cases instead. Thanks - the part about sequential scans and the re-use of a small section of shared_buffers is the bit I was interested in. I don't suppose you would be able to tell me how large that re-useable area might be? Now, with regard to the behavior of table sequential scans: do the stat values in seq_scan and seq_tup_read reflect actual behavior. I assume they do, but I'm just checking - these would be updated as the result of real I/O as opposed to fuzzy estimates? Obviously, the reason I am asking this is that I am noticing high machine io levels that would only result from sequential scan activity. The explain output says otherwise, but the seq_scan stat value for the table kinda correlates. Hence my enquiry. Thanks in advance. Mr -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
