Don't track DEALLOCATE in pg_stat_statements.

We also don't track PREPARE, nor do we track planning time in general, so
let's ignore DEALLOCATE as well for consistency.

Backpatch to 9.4, but not further than that. Although it seems unlikely that
anyone is relying on the current behavior, this is a behavioral change.

Fabien Coelho

diff --git a/contrib/pg_stat_statements/pg_stat_statements.c b/contrib/pg_stat_statements/pg_stat_statements.c
index 6beced0e7d93e0bb9b4a6e0e871de0c1ec34059a..799242ba6a7ef6f159f414bf3fc90bcfe7a25e8b 100644 (file)
--- a/contrib/pg_stat_statements/pg_stat_statements.c
+++ b/contrib/pg_stat_statements/pg_stat_statements.c
@@ -954,10 +954,13 @@ 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.
+        *
+        * Likewise, we don't track execution of DEALLOCATE.
         */
        if (pgss_track_utility && pgss_enabled() &&
                !IsA(parsetree, ExecuteStmt) &&
-               !IsA(parsetree, PrepareStmt))
+               !IsA(parsetree, PrepareStmt) &&
+               !IsA(parsetree, DeallocateStmt))
        {
                instr_time      start;
                instr_time      duration;