On Mon, 2007-03-05 at 09:09 +0000, Heikki Linnakangas wrote:
> In fact, the pages that are left in the cache after the seqscan finishes
> would be useful for the next seqscan of the same table if we were smart
> enough to read those pages first. That'd make a big difference for
> seqscanning a table that's say 1.5x your RAM size. Hmm, I wonder if
> Jeff's sync seqscan patch adresses that.
>
Absolutely. I've got a parameter in my patch "sync_scan_offset" that
starts a seq scan N pages before the position of the last seq scan
running on that table (or a current seq scan if there's still a scan
going).
If the last scan is not still in progress, the pages are less likely to
be in cache. If the pages are in cache, great; if not, it doesn't matter
where we start anyway.
If the last scan is still in progress, those recently-read pages are
very likely to be in cache (shared buffers or OS buffer cache).
Regards,
Jeff Davis
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
