Re: Get rid of pgstat_count_backend_io_op*() functions - Mailing list pgsql-hackers

From Bertrand Drouvot
Subject Re: Get rid of pgstat_count_backend_io_op*() functions
Date
Msg-id aLfvUY1oGFXBpE3G@ip-10-97-1-34.eu-west-3.compute.internal
Whole thread Raw
In response to Re: Get rid of pgstat_count_backend_io_op*() functions  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
Hi,

On Wed, Sep 03, 2025 at 02:47:51PM +0900, Michael Paquier wrote:
> On Tue, Sep 02, 2025 at 12:42:54PM -0400, Andres Freund wrote:
> > 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.
> 
> Even if we only do the diffs calculations when flushing the pending
> stats in the flush callbacks?

If my math are correct we have 3 × 5 × 8 = 120 array positions and for each
we'd do the diff on counts, bytes and times. That means 360 diff operations per
flush. That means 720 diff operations to flush the global and per backend IO
stats. That's certainly more expensive than "just" copying the pending stats
as proposed in v1.

As far the ordering concern for v1, what about:

- let backend kind enum defined as 6
- move the backend flush outside of the loop in pgstat_report_stat()

That way the backend are flushed last and that solves your concern about custom
stats kind.

The backend would not be the "only" exception in pgstat_report_stat(), the db
stats are already handled as exception with pgstat_update_dbstats().

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Steven Niu
Date:
Subject: 回复: Fix segfault while accessing half-initialized hash table in pgstat_shmem.c
Next
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: Logical Replication of sequences