Re: pg_stat_statements cluttered with "DEALLOCATE dbdpg_p*"

> 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:

/*
* If it's an EXECUTE statement, we don't track it and don't
increment the
* nesting level. This allows the cycles to be charged to the
underlying
* PREPARE instead (by the Executor hooks), which is much more
useful.
*
* We also don't track execution of PREPARE. If we did, we would
get one
* hash table entry for the PREPARE (with hash calculated from the
query
* string), and then a different one with the same query string
(but hash
* 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.
*/
if (pgss_track_utility && pgss_enabled() &&
!IsA(parsetree, ExecuteStmt) &&
!IsA(parsetree, PrepareStmt))
... standard handling ...
else
... special "no" handling ...

> So I don't think your consistency argument counts as much here.

I think that given the above code, my argument stands reasonably.

If you do not like my normalization hack (I do not like it much either:-),
I have suggested to add "&& !IsA(parsetree, DeallocateStmt)" to the
condition above, which would ignore DEALLOCATE as PREPARE and EXECUTE are
currently and rightfully ignored.

--
Fabien.