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

First seen: 2026-05-08 23:22:30+00:00 · Messages: 12 · Participants: 2

Latest Update

2026-06-01 · claude-opus-4-6

Monthly Summary: EXPLAIN ANALYZE Wait Event Reporting (May 2026)

Overview

This RFC proposes adding a new EXPLAIN (ANALYZE, WAITS) option that transforms PostgreSQL's wait event subsystem from a point-in-time state indicator into a time-integrated profile. The feature would produce per-statement and per-plan-node wait event breakdowns, answering the DBA question: "During this query, where did time go?"

The thread progressed through three patch versions (v0→v1→v2) during May but received zero technical reviews. The only external interaction was a procedural correction from Michael Paquier about mailing list conventions.

Design Summary

The patch series (7 patches) hooks into the existing pgstat_report_wait_start()/pgstat_report_wait_end() call sites with a single unlikely() branch on a global boolean. When EXPLAIN (ANALYZE, WAITS) is active, wait durations are accumulated into preallocated fixed-size arrays (64 entries per accumulator) with an overflow bucket for queries exceeding 64 distinct wait event types.

Key architectural decisions:

Patch Evolution

v0 → v1 (Process fix)

No code changes. Consolidated seven separate patch emails into a single email per pgsql-hackers conventions, per Michael Paquier's guidance.

v1 → v2 (Test stability)

No accounting-code changes. Fixed regression test failures on FreeBSD CFBot:

Open Review Questions (Unanswered)

  1. Naming: WAITS (terse, matches BUFFERS/WAL/IO) vs WAIT_EVENTS (more discoverable, matches pg_stat_activity terminology)
  2. Inclusive vs exclusive attribution: Should node-level waits be summable (exclusive) or mirror existing timing semantics (inclusive)?
  3. Fixed accumulator limit: Is 64 entries the right bound? Is overflow-bucket semantics acceptable?
  4. Hot-path overhead: Is ~0.1–0.2 ns per disabled wait acceptable? Community will demand Linux-pinned benchmarks.

Status

The patch remains at RFC stage with no technical engagement from committers or reviewers. The design is mature and follows established patterns from prior instrumentation features (BUFFERS, WAL, IO), but has not yet attracted review attention.

History (1 prior analysis)
2026-06-01 · claude-opus-4-6

Incremental Update: v3 Resubmission — Rebase Only, No Code Changes

The sole new message is from the patch author (Ilmar Yunusov) submitting v3 of the series. This is a mechanical rebase over current master after CFBot reported that v2 no longer applied cleanly.

What changed

  1. Rebase conflict in psql tab-completion: Current master already added IO to the EXPLAIN option completion list. v3 preserves IO and adds WAITS alongside it.
  2. Patch count reduced from 8 to 7: The v2 patch that existed solely to keep psql completion current is now obsolete (master already has that change), so it's dropped.

What did NOT change

  • No accounting-code changes from v2.
  • No new tests, no design changes, no benchmark updates.
  • The same four open review questions remain verbatim.
  • The author explicitly notes they did not rerun the regression suite on the fresh rebase worktree.

Assessment

This is a pure "keep CFBot green" maintenance iteration. No technical substance has been added. The thread remains at RFC stage with zero technical reviews from any committer or reviewer.