Re: psql - add special variable to reflect the last query status

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: psql - add special variable to reflect the last query status
Date: 2017-09-12 23:40:24
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Fabien COELHO <coelho(at)cri(dot)ensmp(dot)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

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

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2017-09-12 23:42:28 Re: plpgsql - additional extra checks
Previous Message Stephen Frost 2017-09-12 23:38:40 Re: Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers)