From: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Patches <pgsql-patches(at)postgresql(dot)org>, Jeff Davis <pgsql(at)j-davis(dot)com> |
Subject: | Re: Synchronized scans |
Date: | 2007-06-08 09:50:27 |
Message-ID: | 46692663.9020907@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Tom Lane wrote:
> Heikki Linnakangas <heikki(at)enterprisedb(dot)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.
Right. I was looking at the case where you open a cursor and start
immediately scanning backwards. That's optimized to a rewind.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2007-06-08 10:05:07 | Re: Synchronized scans |
Previous Message | Heikki Linnakangas | 2007-06-08 08:50:49 | Re: Controlling Load Distributed Checkpoints |