pgsql: Improve contrib/pg_stat_statements' handling of PREPARE/EXECUTE

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Improve contrib/pg_stat_statements' handling of PREPARE/EXECUTE
Date: 2012-03-29 20:42:34
Message-ID: E1SDMB0-0002vV-FY@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2012-03-29 21:53:12 pgsql: Fix dblink's failure to report correct connection name in error
Previous Message Tom Lane 2012-03-29 19:33:07 pgsql: Improve handling of utility statements containing plannable stat