Hi, On Mon, Jul 6, 2026, Robert Haas wrote: > If, on the other hand, we use an external sampler, then that concern > largely goes away ...
I looked at this while reviewing Dmitry Fomin's wait-event timing and tracing series. External sampling seems easier to make cross-platform. On Unix, a timer signal handler can run asynchronously in the measured backend. On Windows, PostgreSQL emulates setitimer() with a per-backend timer thread that queues SIGALRM; the main backend thread dispatches it later when it services the signal event or checks for interrupts. On Windows, self-sampling would therefore run at signal dispatch points rather than with Unix signal-handler semantics; when the backend is waiting, each sample would also wake its wait primitive. A separate sampler can use its own WaitLatch timeout and read the published wait event and active plan node without interrupting the target. It would still need the query/node identity and result-return protocol Robert described, but the sampling mechanism itself would be the same on Unix and Windows. Whichever collection method we choose, I think the parallel aggregation semantics need to be explicit. The v3 patch accumulates process wait time across the leader and workers, even when the intervals overlap and describe opposite sides of the same delay. When I toyed a bit with the patch, I forced a parallel scan over 1000 rows executing pg_sleep(0.001), with two workers and parallel_leader_participation=off. Execution Time was 780 ms, while the statement summary included 1133 ms of Timeout:PgSleep in the workers and 777 ms of IPC:ExecuteGather in the leader. This is useful information, but it is not a decomposition of query time, and the totals may greatly exceed Execution Time. Per-worker detail might make the result easier to interpret. Thank you! Best regards, Andrey Borodin.
