Re: Re[2]: [PATCH] pg_stat_statements: add last_execution_start column
Pavlo Golub <pavlo.golub@cybertec.at>
From: Pavlo Golub <pavlo.golub@cybertec.at>
To: Sami Imseih <samimseih@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2026-04-14T16:15:50Z
Lists: pgsql-hackers
Attachments
- v3-0001-pg_stat_statements-Add-last_execution_start-colum.patch (application/octet-stream) patch v3-0001
> > I think adding to queryDesc->EState just like we do for other fields > that are consumed by pg_stat_statements, i.e. es_processed, > es_parallel_workers_to_launch, etc. is the proper pattern. Yeah, makes sense. Thanks. > If we track the start time in queryDesc->EState, this will not be a > problem. For utility > statements, we can rely on a direct call to GetCurrentStatementStartTimestamp() Thank you for the review. v3 addresses all concerns, I hope. I switched from a bounded static array to statement start timestamp stored in EState. The field is set in pgss_ExecutorStart immediately after standard_ExecutorStart creates the estate. All pg_stat_statements regression tests pass (16/16). Benchmark (16-vCPU, pgbench -c8 -j4 -T60): master HEAD: ~4691 TPS (runs: 4849, 4588, 4635) Patched v3: ~4744 TPS (runs: 4870, 4735, 4627) Difference: ~1.1% No measurable overhead. The latest v3 patch attached. > > We also need to document that for toplevel = false statements, this > execution_start time > is that of the top level statement. I think that is acceptable. Docs updated > > -- > Sami Imseih > Amazon Web Services (AWS)
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