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/[email protected] 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
signature.asc
Description: PGP signature
