On Thu, 2006-12-07 at 00:32 -0600, Jim C. Nasby wrote:
> On Thu, Dec 07, 2006 at 12:46:34AM -0500, 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?
>
> 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
That requires that scans clear the hint when they finish, right? I don't
think that would be difficult, but my current patch doesn't do that.
> 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.
Interesting idea.
Regards,Jeff Davis