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
