From 3cd934f635699b7c8b0027be69fddfc36be6f9b8 Mon Sep 17 00:00:00 2001 From: Heikki Linnakangas Date: Mon, 25 Aug 2014 19:13:24 +0300 Subject: [PATCH] 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 --- contrib/pg_stat_statements/pg_stat_statements.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/contrib/pg_stat_statements/pg_stat_statements.c b/contrib/pg_stat_statements/pg_stat_statements.c index 6beced0e7d..799242ba6a 100644 --- 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; -- 2.40.0