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 [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
