Re: [PATCH v1 0/7] Wait event timing and tracing instrumentation

On Fri, Jul 03, 2026 at 10:22:58PM +0200, Dmitry Fomin wrote:
> PostgreSQL exposes a rich taxonomy of wait events in pg_stat_activity,
> but only as instantaneous snapshots: there is no in-core way to ask
> "how long do my backends actually spend in each wait?", or "what was
> the wait sequence of this session's last N events?". External tools
> either sample at coarse resolution (pg_wait_sampling, default 10 ms) or
> pay ~200-300 ns per transition via hardware watchpoints.
>
> This is a reworked submission of an earlier 8k-line single patch,
> following Andrey Borodin's advice to split it into independently
> committable pieces with the DSA machinery deferred. The series has
> three groups; each patch builds and passes check-world on its own:

Please also see this thread, particularly the second message (posted
one year + 4 days ago):
https://www.postgresql.org/message-id/aGKSzFlpQWSh/+2w(at)ip-10-97-1-34(dot)eu-west-3(dot)compute(dot)internal
https://www.postgresql.org/message-id/xuynb44ql3hhggvqtme7axbliww7gwuy6pbaohxc4ngu3ynbsi%40rvvpjxf55aia

The core point that seems to matter most is in v1-0002, where the
patch decides to make what is now a cheap 32-bit volatile manipulation
into an optional compilation-based expensive operation. I don't want
to sound negative here, but I'd recommend to re-read the previous
thread. This kind of change could lead us to make the addition of
more wait events harder to think about, especially if these are in
deeper parts of the backend stack.
--
Michael