Re: [PATCH] pg_stat_statements: add last_execution_start column
Sami Imseih <samimseih@gmail.com>
From: Sami Imseih <samimseih@gmail.com>
To: Pavlo Golub <pavlo.golub@cybertec.at>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2026-03-30T21:33:05Z
Lists: pgsql-hackers
Hi, It would be really great to get this field in, but I think the current implementation still suffers from the same issue that is mentioned here [1]. We cannot rely on GetCurrentStatementStartTimestamp() in-line because ExecutorEnd is deferred to the next execution in the case of extended query protocol. I think we need to add it to track the start timestamp in queryDesc. What do you think? ``` select pg_stat_statements_reset(); BEGIN; select now() as now, clock_timestamp() as clock_timestamp, pg_sleep($1) \bind 10 \g \! sleep 10 SELECT now() as now, clock_timestamp() as clock_timestamp, $1 \bind 1 \g END; select last_execution_start, total_exec_time, substr(query, 1, 150) as query from pg_stat_statements; ``` Notice how the last_execution_start reflects when the "SELECT now() as now, clock_timestamp() as clock_timestamp, $1 " runs -- Sami [1] [https://www.postgresql.org/message-id/CAA5RZ0sxPWP2xm8fxhscE%2BcUqC2VSFi9UZ9882BdGZ0MbGQNUA%40mail.gmail.com]
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
pg_stat_statements: Set PlannedStmt to NULL after nested utility execution
- 66366217822e 19 (unreleased) cited