Hi, Thanks, this is useful feedback.
I agree that the current v3 exact-accounting approach has a serious problem: it adds a branch to pgstat_report_wait_start/end(), and when enabled it measures time at every reported wait boundary. That can distort exactly the wait-heavy cases this feature is meant to make visible. So I do not plan to keep pushing the current hot-path accounting model as-is. For a next version, I think the collection model needs to avoid adding any work to pgstat_report_wait_start/end() when the option is disabled, and also avoid materially changing the workload being measured when the option is enabled. I will look at a sampling-based design instead. My current thought is to narrow the first version compared to v3: report where sampled wait time is spent during EXPLAIN ANALYZE, and either omit wait counts or treat them as secondary. The v3 prototype was still useful to explore output shape, statement-level vs plan-node reporting, parallel aggregation, and test stability, but the collection model needs to change. A few questions about the next shape: 1. Would it be better for a first version to aim at statement-level sampled wait event reporting only, and leave plan-node attribution for a later patch? 2. If plan-node attribution is included, does keeping track of the active PlanState only while EXPLAIN ANALYZE has this option enabled sound like a reasonable direction, provided it stays outside pgstat_report_wait_start/end()? 3. For sampling, should I focus on an external sampler rather than backend self-sampling with a timer, to avoid distorting the measured backend? Regards, Ilmar Yunusov The new status of this patch is: Waiting on Author
