On Thu, 2007-06-07 at 22:52 -0400, Tom Lane wrote: > Heikki Linnakangas <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org