Re: Synchronized scans

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

In response to

Responses

Browse pgsql-patches by date

  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