Re: modifying the tbale function

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Islam Hegazy <islheg(at)hotmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: modifying the tbale function
Date: 2007-03-19 03:49:42
Message-ID: 20952.1174276182@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Neil Conway <neilc(at)samurai(dot)com> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2007-03-19 04:46:47 Re: Buildfarm feature request: some way to track/classify failures
Previous Message Tom Lane 2007-03-19 03:40:35 Re: Bug in UTF8-Validation Code?