Hi, On Wed, Oct 01, 2025 at 07:43:31AM +0900, Michael Paquier wrote: > On Tue, Sep 30, 2025 at 10:05:43AM +0000, Bertrand Drouvot wrote: > > On Tue, Sep 30, 2025 at 04:37:25PM +0900, Michael Paquier wrote: > >> Or perhaps you think that the pending data of a stats kind could be > >> different if a kind allows transactional and non-transactional > >> flushes? > > > > Yeah that was my thought: one stats kind could have metrics that are > > transactional > > and some metrics that are non-transactional. This could be possible for > > both variable and fixed stats, that's why I was thinking about having > > 2 pending lists for the variables stats and 2 flush callbacks for fixed > > stats. > > Okay. The first use case that comes into mind here is pgstat_io.c, to > offer periodic reports on analytics (please extend that to the backend > stats for WAL and I/O). In this case, it seems that it would be good > to know about all the stats fields, meaning that a single pending list > is OK. My feeling would be to reuse pgstat_report_stat() and plant a > new argument for the transactional state (or just a bits32 that works > along the force option) with the same threshold for reports, combined > with a new option to allow non-transactional reports (don't see a > point in forcing these and wait on locks, 1-min reports not happening > would not matter if an analytical query takes a few hours). > > It would be better to determine a list of the stats we'd be > interesting in seeing updated without waiting for a query or a > transaction to finish, then design the needs around these > requirements, with a new thread to discuss the matter. The IO stats > are just the first case coming into mind.
Yeah. Also for the relations stats we'd have a mix (for example there is no need to wait for a transaction to finish to report it's related seq_scan if any). I'll work on a list and open a dedicated thread. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
