Re: old synchronized scan patch

On Thu, Dec 07, 2006 at 12:46:34AM -0500, Tom Lane wrote:
> Jeff Davis <pgsql(at)j-davis(dot)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?

The first reader won't find an entry in shared memory, so it will know
it's the first. It could then either always update, or it could check to
see if anyone else has updated shared memory behind it's back; at that
point it could switch to only updating on an actual read.
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)