> Yah. Something I was idly wondering about: suppose we teach ReadBuffer
> to provide an indication whether it had to issue an actual read() or
> found the block in cache? Could it be useful to not report the block
> location to the hint area if we had to actually read()? That would
> eliminate the immediate "pack leader" from the equation. The problem
> is that it seems to break things for the case of the first follower
> joining a seqscan, because the original leader would never report.
> Anyone see the extra idea needed to make this work?
1) How about 2 location hints, one for the actual reads, and one for the
followers ? The actual read() case will write to the one, the followers
to the other. There could be some magic to make the follower which is
getting close to the pack leader to report less often, so that the
follower hint will still be covering cached buffers far behind enough
(tricky business to tune this), and doesn't skip them immediately. Then
some magic to figure out which one to follow... or even try both (at the
start of the scan only), and go with the one you had no actual read()
on, or the smaller one if both had read() or both didn't.
2) Make the pack leader (as in it had to do actual read()) report less
often than the followers (say every 100 read(), while followers report
every 10 - numbers made up, no idea what would work best here). This
will make the followers hint be more likely to be picked up by new
scans, thus better using the existing cache...
Cheers,
Csaba.
