Hi hackers,
This patch adds a `last_execution_start` column to `pg_stat_statements`,
recording the start timestamp of the most recent execution of each
tracked statement.
It supersedes the `stats_last_updated` series discussed here:
https://www.postgresql.org/message-id/flat/CAK7ymc+FxoVswo1ok_xDW-xPG-ZEZ8SAqCUkJ7WF04=0aQDvVQ@mail.gmail.com
The main criticism of that series was performance using
`GetCurrentTimestamp()` inside the stats accumulation. pgbench testing
confirmed the concern of roughly 5–6% TPS regression on a
short-transaction workload.
This patch takes a different approach. Instead of calling
`GetCurrentTimestamp()`, it uses `GetCurrentStatementStartTimestamp()`,
which simply is a variable reading.
There is no syscall and no additional work in the hot path.
Benchmark (16-vCPU, pgbench -c8 -j4 -T60, explicit transactions with 15
SELECT statements each):
master HEAD: ~4574 TPS (runs: 4636, 4585, 4500)
patched: ~4571 TPS (runs: 4577, 4560, 4575)
difference: ~0.1%
The column is initialized to the entry allocation time and updated on
every call to `pgss_store()`. It is reset by
`pg_stat_statements_reset()` but preserved across minmax-only resets,
consistent with `stats_since` semantics.
A monitoring query to find statements that have executed since the last
observation could look like:
SELECT query, calls, last_execution_start
FROM pg_stat_statements
WHERE last_execution_start >= $1 -- e.g. last check timestamp
ORDER BY last_execution_start DESC;
Patch attached.
Best regards,
Pavlo Golub
