pgsql: Improve contrib/pg_stat_statements' handling of PREPARE/EXECUTE - Mailing list pgsql-committers

From Tom Lane
Subject pgsql: Improve contrib/pg_stat_statements' handling of PREPARE/EXECUTE
Date
Msg-id E1SDMB0-0002vV-FY@gemulon.postgresql.org
Whole thread Raw
List pgsql-committers
Improve contrib/pg_stat_statements' handling of PREPARE/EXECUTE statements.

It's actually more useful for the module to ignore these.  Ignoring
EXECUTE (and not incrementing the nesting level) allows the executor
hooks to charge the time to the underlying prepared query, which
shows up as a stats entry with the original PREPARE as query string
(possibly modified by suppression of constants, which might not be
terribly useful here but it's not worth avoiding).  This is much more
useful than cluttering the stats table with a distinct entry for each
textually distinct EXECUTE.

Experimentation with this idea shows that it's also preferable to ignore
PREPARE.  If we don't, we get two stats table entries, one with the query
string hash and one with the jumble-derived hash, but with the same visible
query string (modulo those constants).  This is confusing and not very
helpful, since the first entry will only receive costs associated with
initial planning of the query, which is not something counted at all
normally by pg_stat_statements.  (And if we do start tracking planning
costs, we'd want them blamed on the other hash table entry anyway.)

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/566a1d43cf6bfcc7f9385b581d98e07eab282cdd

Modified Files
--------------
contrib/pg_stat_statements/pg_stat_statements.c |   19 +++++++++++++++++--
1 files changed, 17 insertions(+), 2 deletions(-)


pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: pgsql: Improve handling of utility statements containing plannable stat
Next
From: Tom Lane
Date:
Subject: pgsql: Fix dblink's failure to report correct connection name in error