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.