From: | Mark Rostron <mrostron(at)ql2(dot)com> |
---|---|
To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: questions regarding shared_buffers behavior |
Date: | 2010-11-08 00:33:37 |
Message-ID: | FD020D3E50E7FA479567872E5F5F31E3045A218A2F@ex01.corp.ql2.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
> >
> > 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
From | Date | Subject | |
---|---|---|---|
Next Message | Marti Raudsepp | 2010-11-08 02:35:46 | Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? |
Previous Message | Greg Smith | 2010-11-08 00:05:19 | Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? |