On Sun, Aug 13, 2023 at 03:25:33PM +0900, Michael Paquier wrote:
> On Tue, Aug 01, 2023 at 10:46:58AM +0800, Julien Rouhaud wrote:
> >
> > Agreed, it should be as trivial to implement as for the 2pc commands :)
>
> Perhaps not as much, actually, because I was just reminded that
> DEALLOCATE is something that pg_stat_statements ignores. So this
> makes harder the introduction of tests.
Maybe it's time to revisit that? According to [1] the reason why
pg_stat_statements currently ignores DEALLOCATE is because it indeed bloated
the entries but also because at that time the suggestion for jumbling only this
one was really hackish.
Now that we do have a sensible approach to jumble utility statements, I think
it would be beneficial to be able to track those, for instance to be easily
diagnose a driver that doesn't rely on the extended protocol.
> Anyway, I guess that your own
> extension modules have a need for a query ID compiled with these
> fields ignored?
My module has a need to track statements and still work efficiently after that.
So anything that can lead to virtually an infinite number of pg_stat_statements
entries is a problem for me, and I guess to all the other modules / tools that
track pg_stat_statements. I guess the reason why my module is still ignoring
DEALLOCATE is because it existed before pg 9.4 (with a homemade queryid as it
wasn't exposed before that), and it just stayed there since with the rest of
still problematic statements.
> For now, I have applied the 2PC bits independently, as of 638d42a.
Thanks!
[1] https://www.postgresql.org/message-id/flat/alpine.DEB.2.10.1404011631560.2557%40sto