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

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