pgsql: Improve handling of utility statements containing plannable stat

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Improve handling of utility statements containing plannable stat
Date: 2012-03-29 19:33:07
Message-ID: E1SDL5n-0001uh-HS@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Improve handling of utility statements containing plannable statements.

When tracking nested statements, contrib/pg_stat_statements formerly
double-counted the execution costs of utility statements that directly
contain an executable statement, such as EXPLAIN and DECLARE CURSOR.
This was not obvious since the ProcessUtility and Executor hooks
would each add their measured costs to the same stats table entry.
However, with the new implementation that hashes utility and plannable
statements differently, this showed up as seemingly-duplicate stats
entries. Fix that by disabling the Executor hooks when the query has a
queryId of zero, which was the case already for such statements but is now
more clearly specified in the code. (The zero queryId was causing problems
anyway because all such statements would add to a single bogus entry.)

The PREPARE/EXECUTE case still results in counting the same execution
in two different stats table entries, but it should be much less surprising
to users that there are two entries in such cases.

In passing, include a CommonTableExpr's ctename in the query hash.
I had left it out originally on the grounds that we wanted to omit all
inessential aliases, but since RTE_CTE RTEs are hashing their referenced
names, we'd better hash the CTE names too to make sure we don't hash
semantically different queries the same.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/e0e4ebe38469a777e3c585e1d97383f974c19b8c

Modified Files
--------------
contrib/pg_stat_statements/pg_stat_statements.c | 37 ++++++++++++++++++-----
1 files changed, 29 insertions(+), 8 deletions(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2012-03-29 20:42:34 pgsql: Improve contrib/pg_stat_statements' handling of PREPARE/EXECUTE
Previous Message Peter Eisentraut 2012-03-29 18:39:17 pgsql: initdb: Mark more messages for translation