On Tue, Jul 06, 2004 at 08:45:52AM +1200, Oliver Jowett wrote:
> Buffering *all* the ResultSet data client-side isn't an option --
> cursors are used specifically to handle resultsets that don't fit into
> heap on the client side. And implementing a disk cache or similar a)
> doesn't work if you don't have disk access, b) is bandwidth-intensive
> and c) is really silly -- that's work that belongs on the server side,
> or why bother with implementing cursors at all?!
Well, the proposal of implementing it like holdable cursors means using
a Materialize node which, if I understand correctly, means taking the
whole result set and storing it on memory (or disk). So the same
question arises: why bother implementing that at all? Of course the
answer is that the server definitely _has_ to provide the functionality.
Now, the cursor problem is beyond me ATM -- it needs deep understanding
of the executor code that I do not have and won't be able to develop in
two weeks ... if there's no reasonable solution in sight maybe the best
we can do is revert the whole nested xacts patch (or at least disable
the funcionality) so we have more time to solve this particular problem.
Sadly, AFAICS this is the only major problem with the functionality, so
it would be a pity to throw away all work only for this.
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"I call it GNU/Linux. Except the GNU/ is silent." (Ben Reiter)