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,

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

I might go so far as to suggest if the scan *ever* moves backwards, we
taint the scan such that it never reports.

        Jeff Davis

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?


Reply via email to