You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
"Why NOTICE rather than pgss: DO-wrappers hide per-statement rows from pg_stat_statements..."
The choice is functional but has a real observer effect on the metric being measured: every RAISE NOTICE produces a server→client protocol message AND a server-side log write, both of which add latency to the very queries being instrumented.
Why this matters
Two compounding costs:
Server→client protocol overhead.RAISE NOTICE flushes a NoticeResponse on each invocation; the client (psql/pgbench/etc.) must read it. At high TPS this is non-trivial.
Combined, RAISE NOTICE-based instrumentation has a higher floor than pg_stat_statements-based measurement.
Why DO blocks were used
DO blocks let arbitrary PL/pgSQL run without persisting a function definition. But pg_stat_statements records the OUTER DO statement (or sometimes nothing, depending on version) — not the inner per-statement timings.
Alternatives for next bench cycle
Replace DO blocks with named functions for the hot-path measurement points. pg_stat_statements then captures per-call statistics with negligible observer effect at typical TPS.
Use pg_stat_kcache or pg_stat_statements.toplevel = on (PG 14+) to capture nested call stats that include DO contents.
Accept DO + use pg_ash 1Hz sampling (already in the pgque bench stack) which is lower-overhead than NOTICE for high-frequency events; reserve NOTICE for boundary events only.
Switch to auto_explain with log_min_duration_sample — less per-query log volume but still useful for outlier diagnosis.
quantify the NOTICE overhead with a comparison run (NOTICE vs no-NOTICE for the same workload), then either move to functions+pgss or accept the overhead with a measured floor.
update the methodology doc with the comparison.
Severity
LOW — methodology refinement, not a numerical correction. Joins the cluster with #123 (log I/O) and #124 (planner-cost framing) as bench-doc revisits for the next round.
Summary
benchmark/documentation (PR #66) explains:The choice is functional but has a real observer effect on the metric being measured: every
RAISE NOTICEproduces a server→client protocol message AND a server-side log write, both of which add latency to the very queries being instrumented.Why this matters
Two compounding costs:
RAISE NOTICEflushes a NoticeResponse on each invocation; the client (psql/pgbench/etc.) must read it. At high TPS this is non-trivial.Combined,
RAISE NOTICE-based instrumentation has a higher floor thanpg_stat_statements-based measurement.Why DO blocks were used
DO blocks let arbitrary PL/pgSQL run without persisting a function definition. But
pg_stat_statementsrecords the OUTERDOstatement (or sometimes nothing, depending on version) — not the inner per-statement timings.Alternatives for next bench cycle
pg_stat_statementsthen captures per-call statistics with negligible observer effect at typical TPS.pg_stat_kcacheorpg_stat_statements.toplevel = on(PG 14+) to capture nested call stats that include DO contents.pg_ash1Hz sampling (already in the pgque bench stack) which is lower-overhead than NOTICE for high-frequency events; reserve NOTICE for boundary events only.auto_explainwithlog_min_duration_sample— less per-query log volume but still useful for outlier diagnosis.Action
Severity
LOW — methodology refinement, not a numerical correction. Joins the cluster with #123 (log I/O) and #124 (planner-cost framing) as bench-doc revisits for the next round.
Related