On Thu, 2007-06-07 at 22:52 -0400, Tom Lane wrote:
> Heikki Linnakangas <heikki@enterprisedb.com> writes:
> > I fixed a little off-by-one in "backward scan, not inited" branch, but I
> > was unable to test it. It seems that code is actually never used because
> > that case is optimized to a rewind in the executor. I marked those
> > seemingly unreachable places in the code with a comment.
>
> Actually it's not equivalent to a rewind, it's more like the startup
> condition for an Index Scan Backward: start at the far end of the
> relation and go backwards. I suspect that the whole thing may be
> unreachable code because the planner knows that seqscans are unordered
> and backward-scan is only of interest for an ordered scan. But be that
> as it may: do we even want a backwards-running scan to participate in a
> syncscan group? Unless *all* the backends are doing the same thing,
> it will not help and instead will bollix the syncscan for everyone else.
> I'm inclined to disable use of syncscan.c altogether when the scan is
Just to be sure: a backwards-started scan is currently unreachable code,
correct?
But as long as the code is there (reachable or not) it sounds good to
disable sync scan in that case.
> started backwards. It also seems prudent to suppress ss_report_location
> calls when stepping backward in a generally-forwards scan. Thoughts?
I agree that we should disable ss_report_location if the scan is moving
backwards.
I might go so far as to suggest if the scan *ever* moves backwards, we
taint the scan such that it never reports.
Regards,
Jeff Davis
