| 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: | Whole Thread | Raw Message | 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 |