[PATCH] pg_stat_statements: add last_execution_start column

[Pavlo Golub]

Hi hackers,




It supersedes the `stats_last_updated` series discussed here:

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. https://www.postgresql.org/message-id/flat/CAK7ymc+FxoVswo1ok_xDW-xPG-ZEZ8SAqCUkJ7WF04=0aqd...@mail.gmail.com

There is no syscall and no additional work in the hot path.



  master HEAD:  ~4574 TPS (runs: 4636, 4585, 4500)
  patched:      ~4571 TPS (runs: 4577, 4560, 4575)
  difference:   ~0.1%





  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

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. Benchmark (16-vCPU, pgbench -c8 -j4 -T60, explicit transactions with 15 SELECT statements each): 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:

v1-0001-pg_stat_statements-Add-last_execution_start-colum.patch
Description: Binary data