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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
