Fabien COELHO <coelho@cri.ensmp.fr> writes:
> See v9 attached.
I've pushed this with some editorialization.
> I put back SetResultVariables function which is called twice, for SQL
> queries and the new descriptions. It worked out of the box with DECLARE
> which is just another SQL statement, so maybe I did not understood the
> cursor issue you were signaling...
No, I was concerned about ExecQueryUsingCursor(), which is used when
FETCH_COUNT is enabled. It's sort of a pain because you have to
accumulate the row count across multiple PGresults. If you don't,
then FETCH_COUNT mode isn't transparent, which it's supposed to be.
I did some performance testing of my own, based on this possibly-silly
test case:
perl -e 'for($i=0;$i<9999999;$i++) {print "set enable_seqscan=0;\n";}' | psql -q
The idea was to run a trivial query and minimize all other psql overhead,
particularly results-printing. With this, "perf" told me that
SetResultVariables and its called functions accounted for 1.5% of total
CPU (including the server processes). That's kind of high, but it's
probably tolerable considering that any real application would involve
both far more server work per query and far more psql work (at least for
SELECTs).
One thing we could think about if this seems too high is to drop
ROW_COUNT. I'm unconvinced that it has a real use-case, and it seems
to be taking more than its share of the work in non-error cases, because
it turns out that PQcmdTuples() is not an amazingly cheap function.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers