From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: Hmm, nodeUnique doesn't really support backwards scan too well |
Date: | 2008-08-07 19:46:45 |
Message-ID: | 87proksj4q.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>>> ... I'm not even sure how to fix it (the nasty case is
>>> changing directions partway through the scan); let alone how to fix it in a
>>> way that's obviously enough right to make me feel comfortable in
>>> back-patching.
>
>> It seems like the obvious fix is to just reverse the behaviour -- keep
>> reading backwards until you see the level break then return the
>> previous record from a second slot.
>
> Well, if you think it's easy, the best form of criticism is a patch.
> The change-of-direction problem seems to me to be messy --- not
> insoluble, but messy enough to need beta testing.
Hm, I must have misunderstood the bug because there's a comment in nodeUnique
which claims it already does precisely what I was suggesting:
* We return the first tuple from each group of duplicates (or the last
* tuple of each group, when moving backwards). At either end of the
* subplan, clear the result slot so that we correctly return the
* first/last tuple when reversing direction.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-08-07 19:50:37 | Re: Hmm, nodeUnique doesn't really support backwards scan too well |
Previous Message | John R Pierce | 2008-08-07 17:09:42 | Re: Postgres Vacuum Password |