Re: Seq scans roadmap

Hi Jeff,

On 5/16/07 4:56 PM, "Jeff Davis" <pgsql(at)j-davis(dot)com> 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