Hi Jeff,
On 5/16/07 4:56 PM, "Jeff Davis" <[EMAIL PROTECTED]> wrote:
>> The main benefit of a sync scan will be the ability to start the scan where
>> other scans have already filled the I/O cache with useful blocks. This will
>> require some knowledge of the size of the I/O cache by the syncscan logic,
>> but that's where the largest amount of I/O cache memory (by far) is located.
> I don't think it's necessarily the largest "by far". However, it may be
> the largest.
Compare the size of a 32 block ring buffer (between 256KB and 1024KB) and
16,000,000 KB of RAM on a common server, automatically used to maximum
extent by the OS dynamic I/O caching.
> If you mean that the main benefit of sync scans is to make use of blocks
> that happen to be in cache before the scan began, I disagree.
That's not what I meant.
> I think
> that's a possible benefit, but I was unable to show any huge benefit in
> my tests (someone may be able to on different hardware with different
> test cases).
I agree, I don't think this is worth pursuing.
> The main benefits that I see are:
> (1) reduce total number of blocks read from disk by making use of
> blocks as they are read by another concurrent seqscan.
> (2) eliminate the need for random I/O on concurrent sequential scans.
Yes on (1), but with (2), again, the OS prefetch reduces the seeking to a
minimal level.
With (1), we just have to define the meaning of "concurrent" to be "within
the span of the OS I/O cache" and we're describing the same effect.
- Luke
---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
