Re: Get rid of pgstat_count_backend_io_op*() functions

On Mon, Sep 01, 2025 at 02:07:27PM +0000, Bertrand Drouvot wrote:
> Instead, it now copies the IO pending stats to the backend IO pending stats when
> the pending IO stats are flushed. This behaves the same way as for some relation
> and database stats (see pgstat_relation_flush_cb()).
>
> It's done that way to avoid incrementing the "same" counters twice as it produces
> increased overhead in profiles (reported by Andres in [1]).

So, is the complaint about the addition of the extra incrementations
for backend counters on top of the existing IO counters in v17,
leading to more instructions generated, the addition of the functions,
or both things at the same time?  Do you have an example of profile
and/or workload where this actually matters?  I am aware that you are
doing crazy things in this area, so..

Also, how much does it matter for v18?  Removing both function calls
and counter incrementations implies refactoring that touches both the
I/O stats and the backend counterparts, which may not be a a good idea
during RC.  I'd be OK in beta 1~2 for this amount of work, the timing
of the discussion is what it is.  So, depending on the arguments
raised this may warrant a revert for the IO part of the backend stats.

> Please note that per-backend statistics have to be last when we define the
> PGSTAT_KIND_% values in pgstat_kind.h, as some of their pending stats are
> populated while other stats kinds are flushing.

+/*
+ * per-backend statistics has to be last, as some of their pending stats are
+ * populated while other stats kinds are flushing.
+ */
+#define PGSTAT_KIND_BACKEND    12    /* per-backend statistics */

I don't think that adding ordering dependencies for the stats kinds is
a good concept in general.  What makes you think that we could not
have a custom pgstats kind willing to increment backend counters as
well, say if we have a table AM with its own stats, for example?

Removing both the function calls and the extra counter incrementations
means to do the same thing as the WAL stats, where we have one
structure in charge of incrementing the counters, then the data diffs
are fed when flushing the entries in all the stats kinds.  So this
would imply the introduction of an equivalent to WalUsage, but applied
to the IO stats, like a IOUsage, or something like that.
--
Michael