Hi,
On 2025-09-02 08:19:22 +0900, Michael Paquier wrote:
> 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?
The latter, I think.
> Do you have an example of profile and/or workload where this actually
> matters?
It's not a large regression by any means - it shows up when micro-benchmarking
seqscans that are consumed where quickly (e.g. OFFSET large; or count(*)).
> Also, how much does it matter for v18?
I think it's ok for 18. We just don't want to go further down the wrong way. I
objected to this approach in the context of the tuple level counters, where it
matters more, because obviously those are incremented a lot more often.
> 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.
I think that's the wrong direction to go. Diffing stats is far from cheap and
gets more expensive the more detail you add to stats.
EXPLAIN ANALYZE spends a large chunk of the time doing diffing of buffer
access stats, for example. We need to work towards doing less of that stuff,
not more.
Greetings,
Andres Freund
