On Tue, 2007-05-08 at 07:47 -0400, Luke Lonergan wrote: > Heikki, > > On 3A: In practice, the popular modern OS'es (BSD/Linux/Solaris/etc) > implement dynamic I/O caching. The experiments have shown that benefit > of re-using PG buffer cache on large sequential scans is vanishingly > small when the buffer cache size is small compared to the system memory. > Since this is a normal and recommended situation (OS I/O cache is > auto-tuning and easy to administer, etc), IMO the effort to optimize > buffer cache reuse for seq scans > 1 x buffer cache size is not > worthwhile. >
I think 3A is still an interesting idea, but I agree that it needs some results to back it up. Let's save 3A for the next release so that we have more time to see. > To that point - an important factor in achieving max I/O rate for large > tables (> 1 x bufcache) is avoiding the pollution of the CPU L2 cache. > This is commonly in the range of 512KB -> 2MB, which is only important > when considering a bound on the size of the ring buffer. The effect has > been demonstrated to be significant - in the 20%+ range. Another thing > to consider is the use of readahead inside the heapscan, in which case > sizes >= 32KB are very effective. One thing I'd like us to keep in mind is to have a reasonable number of buffers active for a sequential scan. If the number is too small, my sync scans might not even work. Right now my patch only reports every 16 pages, so 32KB (=4 pages) is not going to work for sync scans (I suppose only testing will tell). Regards, Jeff Davis ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly