Re: [RFC PATCH v0 0/7] Add EXPLAIN ANALYZE wait event reporting

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.