From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Subject: | Re: Custom pgstat support performance regression for simple queries |
Date: | 2025-07-23 08:09:54 |
Message-ID: | 08E0B1C3-864B-4FD4-AB9E-2F60967E4E7E@paquier.xyz |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Jul 23, 2025, at 16:33, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
> Maybe we could use a flag, say:
>
> #define PGSTAT_PENDING_IO (1 << 0)
> #define PGSTAT_PENDING_WAL (1 << 1)
> #define PGSTAT_PENDING_SLRU (1 << 2)
>
> and check for a pgstat_pending_mask in pgstat_report_stat() instead?
>
> They would need to set pgstat_pending_mask accordingly when they flush, have
> pending stats though.
The point is just to say to the report path to move further if at least one of the fixed stats kinds has something to flush, then let the loop do its work across all the stats kinds if they have a flush callback, so we don’t really need to mix multiple numbers; we could just have a single boolean flag that any fixed-sized stats kinds can set to let the reporting know that some activity has happened. This would mean that custom fixed-sized kinds would need to interact with this flag as well, but that makes the fast-exit path dirty cheap with or without custom stats kinds.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Álvaro Herrera | 2025-07-23 08:11:03 | Re: Pathify RHS unique-ification for semijoin planning |
Previous Message | Jim Jones | 2025-07-23 08:03:54 | Re: display hot standby state in psql prompt |