Andy Fan <zhihui.fan1...@gmail.com> writes:
> when I fetch from holdable cursor, I found the fact is more complex than I
> expected.
> ...
> why the 3rd time is necessary and will the performance be bad due to this
> design?
If you read the whole cursor output, then close the transaction and
persist the cursor, yes we'll read it twice, and yes it's bad for that
case. The design is intended to perform well in these other cases:
1. The HOLD option isn't really being used, ie you just read and
close the cursor within the original transaction. This is important
because applications are frequently sloppy about marking cursors as
WITH HOLD.
2. You declare the cursor and persist it before reading anything from it.
(This is really the typical use-case for held cursors, IMV.)
FWIW, I don't see any intermediate tuplestore in there when
dealing with a PORTAL_ONE_SELECT query, which is the only
case that's possible with a cursor no?
regards, tom lane
