On Wed, 2007-05-16 at 10:31 -0700, Luke Lonergan wrote:
> I think the analysis on syncscan needs to take the external I/O cache into
> account. I believe it is not necessary or desirable to keep the scans in
> lock step within the PG bufcache.
I partially agree. I don't think we need any huge amount of shared
buffers for the scans to use, and the scans should be able to catch up
by using the OS buffer cache (which is still faster than fetching from
disk).
However, as I said before, I'm worried that, if the ring is too small,
it might not work to my expectations. I will try to test this to
eliminate my doubts.
> 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.
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. 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).
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.
I like the idea of using already-in-cache blocks. The code is there and
it works, but I just didn't see the benefits yet. After I get any issues
with this patch resolved and the reviewers are satisfied, I'd like to
work on it.
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
