benchmark: revisit pgmq-partitioned planner-cost claim — first-query-in-session, not per-query

[NikolayS]

Summary

benchmark/ documentation (PR #66) claims:

"premake=20 (24 partitions steady-state) killed pgmq-partitioned consumer perf (525 TPS vs 6621 with premake=4) due to planner cost across all partitions per query."

The "per query" framing is wrong. PostgreSQL's per-partition planner cost is paid mostly at the first query in a session when the plan cache for the relation is populated — not on every subsequent query in the same connection.

Reference

See https://postgres.ai/blog/20241003-how-does-planning-time-depend-on-number-of-partitions#update-2024-10-04-its-bad-only-for-the-first-query-in-session — measurements show first-query latency dominates, with later queries paying a much smaller cost.

What this means for the bench

The 525 → 6621 TPS gap between premake=20 and premake=4 is real, but the explanation needs to be more precise:

• More plausible cause: the consumer pattern uses many short-lived connections (or PgBouncer in transaction mode that recycles backend connections frequently), so the first-query planner cost is paid frequently.
• Or: something about how the consumer issues queries (e.g., per-partition probes) actually does pay per-query overhead despite the session warmup, but that needs measurement evidence (pg_stat_statements plan_time, EXPLAIN ANALYZE BUFFERS, or pg_ash sampling) to confirm.

Either way, "per query" is not the right framing.

Action

• Do not block the current PR docs: bench methodology + tooling under benchmark/ #66 — bench numbers themselves stand.
• For the next bench cycle, either:
  • measure planner cost vs. session lifecycle directly (pg_stat_statements.plan_time + connection-pool metrics), and reframe the claim accordingly, OR
  • if the result holds for long-lived connections too, identify the real cause and document.

Severity

LOW — methodology refinement, not a numerical correction.

Related

• benchmark: revisit "zero PG log I/O" claim — logging_collector=off still produces journald/disk I/O #123 (similar — log I/O claim refinement)
• PR docs: bench methodology + tooling under benchmark/ #66 (the doc landing this claim)

[NikolayS]

Addressed in PR #66 commit 0aa0d41 — prose corrected. Closing as fixed.

[NikolayS]

Additional fix in PR #66 commit dbfdfeb: removed incorrect PgBouncer reference (bench used direct connections only).