[PATCH] pg_stat_statements: add last_execution_start column
| От | Pavlo Golub |
|---|---|
| Тема | [PATCH] pg_stat_statements: add last_execution_start column |
| Дата | |
| Msg-id | em5619eed4-8913-4ee8-a3cd-9f7101b06b6d@cybertec.at обсуждение исходный текст |
| Ответы |
Re: [PATCH] pg_stat_statements: add last_execution_start column
|
| Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: