Re: Hmm, nodeUnique doesn't really support backwards scan too well

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Hmm, nodeUnique doesn't really support backwards scan too well
Дата
Msg-id 13272.1218033595@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Hmm, nodeUnique doesn't really support backwards scan too well  (Gregory Stark <stark@enterprisedb.com>)
Ответы Re: Hmm, nodeUnique doesn't really support backwards scan too well  (Gregory Stark <stark@enterprisedb.com>)
Список pgsql-bugs
Gregory Stark <stark@enterprisedb.com> writes:
> Hm, that has the nasty side effect that someone who uses SCROLL but doesn't
> fetch backwards much or at all suddenly gets a much more expensive plan than
> if they didn't.

Well, what are they using SCROLL for if they don't need it?

A more plausible objection is that previously, (some) cursors using
SELECT DISTINCT would support backwards fetch even if you hadn't said
SCROLL.  The bug I'm concerned about is only manifest with SELECT
DISTINCT ON, so someone might well be happily using DISTINCT in a way
that is affected.  So there might be apps out there that are working
today and will stop working after this change.  But they are very
clearly breaking the rules so I don't have a huge amount of sympathy for
them.  If we were to take this argument seriously, it would mean that
we'd have to not only complicate ExecUnique but back-patch the result
clear back to 7.4.  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.

            regards, tom lane

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Gregory Stark
Дата:
Сообщение: Re: Hmm, nodeUnique doesn't really support backwards scan too well
Следующее
От: "Lampa"
Дата:
Сообщение: BUG #4341: planner doesn't using index for = operation