From: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, Patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: Synchronized scans |
Date: | 2007-06-08 10:05:07 |
Message-ID: | 466929D3.4000103@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Tom Lane wrote:
> Jeff Davis <pgsql(at)j-davis(dot)com> writes:
>> Just to be sure: a backwards-started scan is currently unreachable code,
>> correct?
>
> [ yawn... ] I think so, but I wouldn't swear to it right at the moment.
> In any case it doesn't seem like a path that we need to optimize.
Agreed, let's just disable the reporting when moving backwards. Jeff's
idea of tainting the whole scan if you ever move backwards is not bad
either, but it's so uncommon that we don't really need to care either way.
BTW: Should we do the synchronization in the non-page-at-a-time mode?
It's not many lines of code to do so, but IIRC that codepath is only
used for catalog access. System tables really shouldn't grow that big,
and if they do we shouldn't be doing seq scans for them anyway. Does the
unstable ordering confuse any catalog accesses?
Here's an update of the patch. I reverted the behavior at end of scan
back to the way it was in Jeff's original patch, and disabled reporting
the position when moving backwards.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
syncscan-mod-4.patch | text/x-diff | 26.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2007-06-08 12:31:54 | COPYable logs status |
Previous Message | Heikki Linnakangas | 2007-06-08 09:50:27 | Re: Synchronized scans |