Re: old synchronized scan patch

"Simon Riggs" <simon@2ndquadrant.com> writes:
> On Wed, 2006-12-06 at 11:46 -0800, Jeff Davis wrote:
>> If you make the join/leave operations such that there is no resistance
>> at all (no timeout or anything), then it becomes the same as my non-
>> synchronized proposal, right?

> Teamwork requires some synchronisation to be effective, but yeh there
> needs to be a way to leave the Conga if its not working for you/them.

Seems like an unworkably complicated mess :-(.  Error cases alone would
be a nightmare.  The good thing about Jeff's proposal is that it's very
robust --- there isn't anything you have to clean up if you abort a scan.

I think all we need as far as buffer management goes is what I suggested
before, namely have seqscans on large tables tell bufmgr not to
increment the usage counter for their accesses.  If it stays zero then
the buffers will be recycled as soon as the sweep gets back to them,
which is exactly what we want.  The window for additional backends to
pick up on the sync scan is then however much of shared_buffers aren't
occupied by blocks being accessed normally.

If we have syncscan members that are spread out over any significant
range of the table's blocks, then the problem of setting the hint
properly becomes a lot more pressing.  We'd like incoming joiners to
start at a fairly low block number, ie not become one of the "pack
leaders" but one of the "trailers" --- since the higher they start,
the more blocks they'll need to re-read at the end of their cycles,
yet those are blocks they could have had "for free" if they'd started
as a trailer.  I don't see any cheap way to bias the behavior in that
direction, though.
        regards, tom lane