On Thu, Oct 12, 2006 at 02:50:34PM -0400, Tom Lane wrote:
> > ISTM that pushing to a tuplestore is a lot of extra work for
>
> I'm not entirely convinced of that --- the overhead of getting down
> through functions.c and ExecutorRun into the per-tuple loop isn't
> trivial either. It wouldn't work at all without significant
> restructuring, in fact, because as execMain stands we'd be firing "per
> statement" triggers once per row if we tried to handle RETURNING queries
> the same way that SQL functions currently handle SELECTs. When you look
> at the big picture there's a whole lot of call overhead that would go
> away if SQL functions returned a tuplestore instead of a row at a time.
> I was toying with the idea that we should make SELECTs return via a
> tuplestore too, which would allow eliminating the special case of having
> ExecutorRun return an individual tuple at all. That's not a bugfix
> though so I'll wait for 8.3 before thinking more about it ...
The specific concern I have is large result sets, like 10s or 100s of MB
(or more). We just added support for not buffering those in psql, so it
seems like a step backwards to have the backend now buffering it (unless
I'm confused on how a tuplestore works...)
--
Jim Nasby jim@nasby.net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
