postgres.git / summary / log / commit / refs

commit    642aadff7ff6704e2afee360ca98b78a4fba6629
Author:   Heikki Linnakangas <heikki.linnakangas@iki.fi>
Date:     Mon Aug 25 16:13:24 2014 +0000

    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 a3e8c595b81..74a8c731fc0 100644
--- a/contrib/pg_stat_statements/pg_stat_statements.c
+++ b/contrib/pg_stat_statements/pg_stat_statements.c
@@ -955,10 +955,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;


[parent: 73e47b703b3b]