Re: pg_stat_statements: Add `calls_aborted` counter for tracking query cancellations

Thanks for starting this thread! I do think it will be valuable to have
an idea of how many calls were aborted. But I am not so sure about
pg_stat_statements being the correct vehicle for this information.

The pg_stat_statements view deals with stats the are updated when a statement
completes execution, so I think it is quite confusing to add this metric to
pg_stat_statements.

> I'm wondering how useful that counter alone will be.  Since
> pg_stat_statements is already quite large,

I agree, but I think it's time to start thinking about splitting
pg_stat_statements into multiple functions. This was recently
discussed [0]

> wouldn't it be better to have
> another extension that tracks something like (queryid, sqlstate),

I think this can be a part of  the pg_stat_statements extension, but as
a separate view, i.e. pg_stat_statements_aborted ( or something ) which
tracks this info.

> > part of the system.  I would have considered using an xact callback
> > when a transaction is aborted if I were to do a patch like the one you
> > are proposing, to know how many times a transaction is failing at a
> > specific phase,

my 2c is the implementation for such statistics, we need to count
when execution starts and when execution ends. The difference in those
2 values give us the aborted calls count.

When we rely on the transaction callbacks, we assume we reach that
hook ( which will occur during normal transaction cleanup ), but I am thinking
of other cases, which are quite common, in which the application times out
and causes the connection to drop. By counting the ExecutorStart and
ExecutorEnd,
as described above, we can cover those cases also.

Unfortunately, I think this will not be very performant to do the way
I describe it
above with the way pg_s_s currently works. As it means we will need to
take an additional spinlock at executor start to count this.

I do think that if we move pg_s_s to using pluggable stats [1], we
have an opportunity
to do something like this.

( FWIW, I also think it will be good to have a calls_stated and
called_completed counter at a higher
level also, as in pg_stat_database. )

[0] https://www.postgresql.org/message-id/aHdAQskQCjGWOdfi%40paquier.xyz
[1] https://www.postgresql.org/message-id/aKF0V-T8-XAxj47T%40paquier.xyz


--
Sami