>>> 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.
>
>> Well, EXECUTE isn't actually ignored, but tracked via the execution
>> time. But that doesn't diminish your point with PREPARE. If we do
>> something we should go for the && !IsA(parsetree, DeallocateStmt), not
>> the normalization. The latter is pretty darn bogus.
>
> Agreed. I think basically the reasoning here is "since we don't track
> PREPARE or EXECUTE, we shouldn't track DEALLOCATE either".
Yes. It is not just because it is nicely symmetric, it is also annoying to
have hundreds of useless DEALLOCATE stats in the table.
> However, this is certainly a behavioral change. Perhaps squeeze it
> into 9.4,
That would be nice, and the one-liner looks safe enough.
> but not the back braches?
Yep. I doubt that pg_stat_statements users rely on statistics about
DEALLOCATE, so back patching the would be quite safe as well, but I would
not advocate it.
--
Fabien.
