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 http://www.postgresql.org/about/donate