Re: old synchronized scan patch

Tom Lane wrote:
> Jeff Davis <pgsql@j-davis.com> writes:
>> Even if there are 50 in the pack, and 2 trailing, at any point in time
>> it's more likely that the last block number reported was reported by a
>> trailing scan. The pack might all report at once when they finally get
>> the block, but will be promptly overwritten by the continuous stream of
>> reports from trailing scans.
> 
>> However, if my analysis was really true, one might wonder how those
>> scans got that far behind in the first place.
> 
> 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?

What if there were two blocknumbers (last_disk_read_blocknr, and last_cache_read_blocknr)
stored per table, together with a timestamp telling when the last updated occured?
Values older than let's say a second or so would be treated as "outdated".

If last_cache_read_blocknr isn't outdated, it would be used as a starting point for seqscans,
otherwise last_disk_read_blocknr would be used if that one isn't outdated. If both are
outdates, it would start at the lower of the two blocknumbers.

greetings, Florian Pflug