Re: [HACKERS] Cursor with hold emits the same row more than once across commits in 8.3.7

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] Cursor with hold emits the same row more than once across commits in 8.3.7
Дата
Msg-id 603c8f070906091037l3a748fc8m11ca40cb4b7fe8f7@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Cursor with hold emits the same row more than once across commits in 8.3.7  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
On Tue, Jun 9, 2009 at 12:07 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> The technically best solution is probably similar to what Materialize
> nodes do, ie, read the query only once and be careful to stash rows
> aside into a tuplestore as they are read.  This would fix both issues
> with one patch.  The problem with that is that if the user doesn't
> actually do any backwards fetching, you waste all the tuplestore
> maintenance work.

This seems like the only option that will produce correct answers, so
it gets my vote.  How much is the performance penalty for
materializing the tuplestore?  I'm inclined to think that whatever it
is, you just have to pay it if you ask for a WITH HOLD cursor.

I suppose in theory you could try to figure out whether
materialization is really necessary (let's see... no seqscans here and
no volatile functions...  ok, so we can cheat...) but that seems
likely to lead to future bugs as the rules for which things are safe
change.

...Robert


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

Предыдущее
От: "Kevin Grittner"
Дата:
Сообщение: Re: [HACKERS] Cursor with hold emits the same row more than once across commits in 8.3.7
Следующее
От: Jaime Casanova
Дата:
Сообщение: Re: [HACKERS] Cursor with hold emits the same row more than once across commits in 8.3.7