Simon, You may know we've built something similar and have seen similar gains. We're planning a modification that I think you should consider: when there is a sequential scan of a table larger than the size of shared_buffers, we are allowing the scan to write through the shared_buffers cache.
The hypothesis is that if a relation is of a size equal to or less than the size of shared_buffers, it is "cacheable" and should use the standard LRU approach to provide for reuse. - Luke On 3/12/07 3:08 AM, "Simon Riggs" <[EMAIL PROTECTED]> wrote: > On Mon, 2007-03-12 at 09:14 +0000, Simon Riggs wrote: >> On Mon, 2007-03-12 at 16:21 +0900, ITAGAKI Takahiro wrote: > >>> With the default >>> value of scan_recycle_buffers(=0), VACUUM seems to use all of buffers in >>> pool, >>> just like existing sequential scans. Is this intended? >> >> Yes, but its not very useful for testing to have done that. I'll do >> another version within the hour that sets N=0 (only) back to current >> behaviour for VACUUM. > > New test version enclosed, where scan_recycle_buffers = 0 doesn't change > existing VACUUM behaviour. ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
