Re: [BUG]: the walsender does not update its IO statistics until it exits
От | Bertrand Drouvot |
---|---|
Тема | Re: [BUG]: the walsender does not update its IO statistics until it exits |
Дата | |
Msg-id | aN044hUO6xvHhNf9@ip-10-97-1-34.eu-west-3.compute.internal обсуждение исходный текст |
Ответ на | Re: [BUG]: the walsender does not update its IO statistics until it exits (Michael Paquier <michael@paquier.xyz>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: