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
started backwards. It also seems prudent to suppress ss_report_location
calls when stepping backward in a generally-forwards scan. Thoughts?
regards, tom lane