Neil Conway <[EMAIL PROTECTED]> writes:
> Returning control to the backend for every row returned would likely be 
> excessive, but you could return once every k rows and get most of the 
> benefits of both approaches (k might be on the order of 1000).

However, this still leaves us with no idea how to persuade perl, tcl,
python, et al to cooperate.

I think you are underestimating the cost of suspending/resuming any of
those interpreters, and overestimating the cost of a tuplestore, which
on a per-tuple basis is really pretty cheap.  It's quite likely that the
proposed project would produce piddling or negative gains, after
expending a huge amount of work.  (A tenth of the effort on optimizing
tuplestore some more would probably be a better investment.)

A cross-check on this theory could be made without a lot of effort: hack
SQL functions to use a tuplestore (fed via the tuplestore destreceiver,
so as not to exit the executor) instead of return-after-every-tuple.
Compare performance.  I kinda suspect you'll find it a loss even there.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at


Reply via email to