That's because PREPARE isn't executed as it's own statement, but done on
the protocol level (which will need noticeably fewer messages). There's
no builtin logic to ignore actual PREPARE statements.
ISTM that there is indeed a special handling in function
pgss_ProcessUtility for PREPARE and EXECUTE:
[...]
For completeness purpose, here is the one-liner patch to handle DEALLOCATE
as PREPARE & EXECUTE are handled. It is cleaner than the other one, but
then DEALLOCATE disappear from the table, as PREPARE and EXECUTE do.
--
Fabien.
diff --git a/contrib/pg_stat_statements/pg_stat_statements.c b/contrib/pg_stat_statements/pg_stat_statements.c
index 07f09e1..a8000cb 100644
--- a/contrib/pg_stat_statements/pg_stat_statements.c
+++ b/contrib/pg_stat_statements/pg_stat_statements.c
@@ -955,10 +955,14 @@ pgss_ProcessUtility(Node *parsetree, const char *queryString,
* calculated from the query tree) would be used to accumulate costs of
* ensuing EXECUTEs. This would be confusing, and inconsistent with other
* cases where planning time is not included at all.
+ *
+ * DEALLOCATE of prepared statement is skip, especially as some drivers
+ * use process/counter-based names which end up cluttering the stats table.
*/
if (pgss_track_utility && pgss_enabled() &&
!IsA(parsetree, ExecuteStmt) &&
- !IsA(parsetree, PrepareStmt))
+ !IsA(parsetree, PrepareStmt) &&
+ !IsA(parsetree, DeallocateStmt))
{
instr_time start;
instr_time duration;
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
