public inbox for [email protected]
help / color / mirror / Atom feedRe[2]: [PATCH] Add last_executed timestamp to pg_stat_statements
10+ messages / 3 participants
[nested] [flat]
* Re[2]: [PATCH] Add last_executed timestamp to pg_stat_statements
@ 2025-12-11 11:31 Pavlo Golub <[email protected]>
2025-12-11 16:35 ` Re: Re[2]: [PATCH] Add last_executed timestamp to pg_stat_statements Sami Imseih <[email protected]>
0 siblings, 1 reply; 10+ messages in thread
From: Pavlo Golub @ 2025-12-11 11:31 UTC (permalink / raw)
To: Sami Imseih <[email protected]>; +Cc: [email protected]
Hi
>Hi,
>
>Thanks for raising this. I did not look at the patch, but I have some high
>level comments.
>
>> I would like to propose adding a last_executed timestamptz column to
>> pg_stat_statements. This column records when each tracked statement
>> was most recently executed.
>
>I do think there is value in adding a last_executed timestamp.
Thanks for your support!
>Can pg_stat_statements.stats_since help here?
>
>for example "where stats_since > last_poll_timestamp" ?
Actually no, monitoring tools fetch snapshots to find the difference
between snapshots.
Data for every statement is changes after each execution.
But stats_since is inserted only once when the new statement execution
appears and is never updated during next executions.
>
>
>The client does have to track the last_poll_timestamp in that
>case.
>
>[0] https://www.postgresql.org/message-id/flat/CAA5RZ0s9SDOu+Z6veoJCHWk+kDeTktAtC-KY9fQ9Z6BJdDUirQ@mail....
>[1] https://www.postgresql.org/message-id/03f82e6f-66a3-4c4d-935c-ea4d93871dc1%40gmail.com
>
>--
>Sami Imseih
>Amazon Web Services (AWS)
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Re[2]: [PATCH] Add last_executed timestamp to pg_stat_statements
2025-12-11 11:31 Re[2]: [PATCH] Add last_executed timestamp to pg_stat_statements Pavlo Golub <[email protected]>
@ 2025-12-11 16:35 ` Sami Imseih <[email protected]>
2026-02-06 15:47 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Sami Imseih <[email protected]>
0 siblings, 1 reply; 10+ messages in thread
From: Sami Imseih @ 2025-12-11 16:35 UTC (permalink / raw)
To: Pavlo Golub <[email protected]>; +Cc: [email protected]
> >Can pg_stat_statements.stats_since help here?
> >
> >for example "where stats_since > last_poll_timestamp" ?
>
> Actually no, monitoring tools fetch snapshots to find the difference
> between snapshots.
> Data for every statement is changes after each execution.
>
> But stats_since is inserted only once when the new statement execution
> appears and is never updated during next executions.
I was thinking of using stats_since to avoid fetching query text,
since that does not change. But you are talking about avoiding all
the stats if they have not changed. I see that now.
FWIW, this was discussed back in 2017 [0], and at that time there was
some support for last_executed, but the patch did not go anywhere.
After looking at the patch, I have a few comments:
1/ There are whitespace errors when applying.
2/ Calling GetCurrentTimestamp while holding a spinlock is
not a good idea and should be avoided. This was also a point
raised in [0]. Even when we move pg_stat_statements
to cumulative stats and not at the mercy of the spinlock for updating
entries, i would still hesitate to add an additional GetCurrentTimestamp()
for every call.
I wonder if we can use GetCurrentStatementStartTimestamp()
instead?
```
/*
* GetCurrentStatementStartTimestamp
*/
TimestampTz
GetCurrentStatementStartTimestamp(void)
{
return stmtStartTimestamp;
}
```
stmtStartTimestamp is the time the query started, which seems OK for
the use-case you are mentioning. But also, stmtStartTimestamp gets
set at the top-level so nested entries (toplevel = false ) will just
inherit the timestamp of the top-level entry.
IMO, this is the most important point in the patch for now.
3/ last_executed, or maybe (last_toplevel_start) if we go with #2 should not
be added under pgssEntry->Counters, but rather directory under pgssEntry.
@@ -213,6 +214,7 @@ typedef struct Counters
* launched */
int64 generic_plan_calls; /* number of calls using a generic plan */
int64 custom_plan_calls; /* number of calls using a
custom plan */
+ TimestampTz last_executed; /* timestamp of last statement execution */
} Counters;
4/ instead of a " last_executed" maybe the tests should be added to
entry_timestamp.sql?
[0] https://www.postgresql.org/message-id/flat/CA%2BTgmoZgZMeuN8t9pawSt6M%3DmvxKiAZ4CvPofBWwwVWeZwHe4w%4...
--
Sami Imseih
Amazon Web Services (AWS)
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [PATCH] Add last_executed timestamp to pg_stat_statements
2025-12-11 11:31 Re[2]: [PATCH] Add last_executed timestamp to pg_stat_statements Pavlo Golub <[email protected]>
2025-12-11 16:35 ` Re: Re[2]: [PATCH] Add last_executed timestamp to pg_stat_statements Sami Imseih <[email protected]>
@ 2026-02-06 15:47 ` Sami Imseih <[email protected]>
2026-02-09 08:47 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Christoph Berg <[email protected]>
0 siblings, 1 reply; 10+ messages in thread
From: Sami Imseih @ 2026-02-06 15:47 UTC (permalink / raw)
To: Christoph Berg <[email protected]>; +Cc: Pavlo Golub <[email protected]>; Bertrand Drouvot <[email protected]>; [email protected] <[email protected]>
> > WHERE last_execution_start + max_exec_time * INTERVAL '1 ms' > NOW() -
> > polling_interval
>
> Is this extra complexity worth one saved GetCurrentTimestamp()?
>
> src/backend/access/transam/xact.c is calling GetCurrentTimestamp a
> lot already, so I don't really buy the argument it should be avoided
> at all cost in pg_stat_statements. Just storing the statement end time
> would make this use case much nicer.
We do call GetCurrentTimestamp() to set timestamps for xact_start, etc.
But, we also take special care to avoid extra calls.
```
/*
* set transaction_timestamp() (a/k/a now()). Normally, we want this to
* be the same as the first command's statement_timestamp(), so don't do a
* fresh GetCurrentTimestamp() call (which'd be expensive anyway). But
* for transactions started inside procedures (i.e., nonatomic SPI
* contexts), we do need to advance the timestamp. Also, in a parallel
* worker, the timestamp should already have been provided by a call to
* SetParallelStartTimestamps().
*/
if (!IsParallelWorker())
{
if (!SPI_inside_nonatomic_context())
xactStartTimestamp = stmtStartTimestamp;
else
xactStartTimestamp = GetCurrentTimestamp();
```
> OK, here is one more try. I discovered the `total_time` argument to
> the `pgss_store()` function! So we can calculate the finish time
> without calling `GetCurrentTimestamp()`.
>
> This is version 3 of the patch adding a `stats_last_updated` column
> (yes, again) to pg_stat_statements. Based on feedback, this version
> improves the implementation with better performance and correctness.
>
> The main improvement uses `statement_start + execution_duration` with
> `rint(total_time * 1000.0)` to convert milliseconds to microseconds
> with proper rounding. The calculation performed BEFORE acquiring
> spinlock and assigned within locked scope.
Correct, this also crossed my mind. Although I would consider doing things a bit
different. Instead of calculating the end time in a single column, I still
think it's worth having a last_executed_start and a
last_execution_time (duration),
and the user can calculate this on the SQL layer. I think it's better because
last_execution_start is already a known timestamp in
pg_stat_activity.query_start
and some tool that finds a long running query in pg_stat_activity, knowing the
query_start they could then go look it up in pg_stat_statements. What I'm
really getting at is separating these fields will open up more use cases, IMO.
Of course, we are adding 2 new columns instead of just 1, but these values
do have benefits.
--
Sami Imseih
Amazon Web Services (AWS)
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [PATCH] Add last_executed timestamp to pg_stat_statements
2025-12-11 11:31 Re[2]: [PATCH] Add last_executed timestamp to pg_stat_statements Pavlo Golub <[email protected]>
2025-12-11 16:35 ` Re: Re[2]: [PATCH] Add last_executed timestamp to pg_stat_statements Sami Imseih <[email protected]>
2026-02-06 15:47 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Sami Imseih <[email protected]>
@ 2026-02-09 08:47 ` Christoph Berg <[email protected]>
2026-02-09 16:51 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Sami Imseih <[email protected]>
0 siblings, 1 reply; 10+ messages in thread
From: Christoph Berg @ 2026-02-09 08:47 UTC (permalink / raw)
To: Pavlo Golub <[email protected]>; Sami Imseih <[email protected]>; +Cc: Bertrand Drouvot <[email protected]>; [email protected] <[email protected]>
Re: Pavlo Golub
> How about
> TimestampTz stmt_end = TimestampTzPlusMilliseconds(
> GetCurrentStatementStartTimestamp(),
> (int64) total_time
> );
> We have total_time as an argument already! No kernel calls, sweet and easy!
Cool idea!
Re: Sami Imseih
> I think it's better because last_execution_start is already a known
> timestamp in pg_stat_activity.query_start and some tool that finds a
> long running query in pg_stat_activity, knowing the
> query_start they could then go look it up in pg_stat_statements.
That only works if a) the query was not yet overwritten in
pg_stat_activity and b) neither in pg_stat_statements. Optimizing for
that use case seems pretty narrow.
> What I'm really getting at is separating these fields will open up
> more use cases, IMO.
Generally, I think pgss should have cumulative statistics, and less
about individual executions, so I'm not really sure what practical
problem "last start" and "last runtime" would solve. The
last_stats_update column we are talking about here is different in the
sense that it's not about an individual execution, but infrastructure
for retrieving the stats sensibly.
Christoph
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [PATCH] Add last_executed timestamp to pg_stat_statements
2025-12-11 11:31 Re[2]: [PATCH] Add last_executed timestamp to pg_stat_statements Pavlo Golub <[email protected]>
2025-12-11 16:35 ` Re: Re[2]: [PATCH] Add last_executed timestamp to pg_stat_statements Sami Imseih <[email protected]>
2026-02-06 15:47 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Sami Imseih <[email protected]>
2026-02-09 08:47 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Christoph Berg <[email protected]>
@ 2026-02-09 16:51 ` Sami Imseih <[email protected]>
2026-02-16 19:00 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Pavlo Golub <[email protected]>
0 siblings, 1 reply; 10+ messages in thread
From: Sami Imseih @ 2026-02-09 16:51 UTC (permalink / raw)
To: Christoph Berg <[email protected]>; +Cc: Pavlo Golub <[email protected]>; Bertrand Drouvot <[email protected]>; [email protected] <[email protected]>
> > How about
> > TimestampTz stmt_end = TimestampTzPlusMilliseconds(
> > GetCurrentStatementStartTimestamp(),
> > (int64) total_time
> > );
> > We have total_time as an argument already! No kernel calls, sweet and easy!
>
> Cool idea!
This calculation could be wrong for very common cases in extended
query protocol,
Here is a script to test with:
```
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 stats_last_updated, total_exec_time, substr(query, 1, 150) as
query from pg_stat_statements;
````
With v3 applied, notice the output is calculating a stats_last_updated
that is beyond the current time
```
pg_stat_statements_reset
-------------------------------
2026-02-09 16:13:35.188849+00
(1 row)
BEGIN
now | clock_timestamp | pg_sleep
------------------------------+-------------------------------+----------
2026-02-09 16:13:35.18911+00 | 2026-02-09 16:13:35.189397+00 |
(1 row)
now | clock_timestamp | ?column?
------------------------------+-------------------------------+----------
2026-02-09 16:13:35.18911+00 | 2026-02-09 16:13:55.193443+00 | 1
(1 row)
COMMIT
stats_last_updated | total_exec_time |
query
-------------------------------+-----------------+-------------------------------------------------------------------------
2026-02-09 16:13:55.19367+00 | 0.007401 | SELECT now() as
now, clock_timestamp() as clock_timestamp, $1
2026-02-09 16:13:55.193664+00 | 0.00103 | END
2026-02-09 16:13:35.189111+00 | 0.00098 | BEGIN
2026-02-09 16:13:35.188584+00 | 0.090183 | select
pg_stat_statements_reset()
2026-02-09 16:14:05.194134+00 | 10000.751122 | select now() as
now, clock_timestamp() as clock_timestamp, pg_sleep($1)
(5 rows)
```
This happens because in the case of extended query protocol,
ExecutorEnd is called
at the next query. This has been discussed in [1] [2].
So, for this to work, we will likely need to store the query start
time in the queryDesc; actually
queryDesc->totaltime, and set the query start time at ExecutorStart,
during InstrAlloc.
> > I think it's better because last_execution_start is already a known
> > timestamp in pg_stat_activity.query_start and some tool that finds a
> > long running query in pg_stat_activity, knowing the
> > query_start they could then go look it up in pg_stat_statements.
>
> That only works if a) the query was not yet overwritten in
> pg_stat_activity and b) neither in pg_stat_statements. Optimizing for
> that use case seems pretty narrow.
>
> > What I'm really getting at is separating these fields will open up
> > more use cases, IMO.
Maybe this is a bad use case. But I felt separating these 2 fields will
be more flexible.
> Generally, I think pgss should have cumulative statistics, and less
> about individual executions, so I'm not really sure what practical
> problem "last start" and "last runtime" would solve. The
> last_stats_update column we are talking about here is different in the
> sense that it's not about an individual execution, but infrastructure
> for retrieving the stats sensibly.
Sure, generally, pg_stat_statements is for cumulative stats, but we also
do have computed stats such as max/min/stddev, etc. But, it's not without
precedent that we track timestamps of the last time some operation occurred.
We do that in views that have a purpose of tracking cumulative data, because
these timestamps are useful. See pg_stat_all_tables.last_seq_scan or
last_autovacuum
as an example.
Maybe having the last runtime column is not that valuable if we can
correctly calculate
the last execution time. AlsoI will be a strong -1 calling this field
"stats_last_updated"
instead of "last_execution_time".
[1] https://www.postgresql.org/message-id/[email protected]
[2] https://www.postgresql.org/message-id/[email protected]...
--
Sami Imseih
Amazon Web Services (AWS)
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [PATCH] Add last_executed timestamp to pg_stat_statements
2025-12-11 11:31 Re[2]: [PATCH] Add last_executed timestamp to pg_stat_statements Pavlo Golub <[email protected]>
2025-12-11 16:35 ` Re: Re[2]: [PATCH] Add last_executed timestamp to pg_stat_statements Sami Imseih <[email protected]>
2026-02-06 15:47 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Sami Imseih <[email protected]>
2026-02-09 08:47 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Christoph Berg <[email protected]>
2026-02-09 16:51 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Sami Imseih <[email protected]>
@ 2026-02-16 19:00 ` Pavlo Golub <[email protected]>
2026-02-16 22:06 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Sami Imseih <[email protected]>
0 siblings, 1 reply; 10+ messages in thread
From: Pavlo Golub @ 2026-02-16 19:00 UTC (permalink / raw)
To: Sami Imseih <[email protected]>; +Cc: Christoph Berg <[email protected]>; Bertrand Drouvot <[email protected]>; [email protected] <[email protected]>
Hi hackers,
This is v4 of the patch adding a stats_last_updated column to
pg_stat_statements.
The thread is somehow shifted to things that are not related to the
patch initial idea. I decided to return to the beginning.
I simplified the implementation to use GetCurrentTimestamp() directly
instead of calculating the timestamp from
GetCurrentStatementStartTimestamp() + total_time. The previous optimization was
premature, benchmark testing proves GetCurrentTimestamp() adds no
measurable overhead.
Test environment: Dockerized Linux x86_64 under Windows host (the
worst possible combination), PostgreSQL 19devel, gcc-14.2.0
Test: 1,000,000 iterations of PERFORM 1 (fastest possible statement)
Unpatched PostgreSQL:
track='none' (baseline): 562.07ms average
track='all' (tracking): 719.17ms average
Overhead: 157.10ms (27.9%)
Patched PostgreSQL (with stats_last_updated):
track='none' (baseline): 548.95ms average
track='all' (tracking): 732.50ms average
Overhead: 183.55ms (33.4%)
Direct comparison (what matters):
Unpatched track='all': 719.17ms
Patched track='all': 732.50ms
Difference: +13.33ms (+1.85%)
Per-statement: 13.33ms / 1,000,000 = 13 nanoseconds
The baseline comparison shows patched is actually faster (-13ms),
which is impossible.
This confirms the 13ms variance is a measurement noise, not real overhead.
Real-world impact for 100ms query is 0.000013% overhead
GetCurrentTimestamp() is the standard approach used throughout PostgreSQL for
monitoring features. The measured overhead of 13 nanoseconds per statement is
negligible for any realistic workload and well within measurement noise.
The implementation captures GetCurrentTimestamp() before acquiring the spinlock,
so no syscall occurs while holding the lock. This is simple, correct, and has
no measurable performance impact.
Changes from v2-v3:
- Simplified implementation to use GetCurrentTimestamp() directly
- Removed complex calculation with GetCurrentStatementStartTimestamp()
and total_time computation (premature optimization)
- Added comprehensive benchmark testing (unpatched vs patched)
- Benchmark testing shows no measurable overhead (<2% in synthetic tests)
- Measured overhead: 13ns per statement (1.85% for 1M iteration test,
negligible for real queries >0.1ms)
Changes from v1:
- Rename column from last_executed to stats_last_updated (Christoph Berg)
- Move timestamp from Counters struct to pgssEntry for better semantics
- Place column at end of view to match stats_since naming convention
- Fixed whitespace errors
- Moved tests to entry_timestamp.sql (Sami Imseih)
- Updated PGSS_FILE_HEADER to handle structure change
Patch, benchmark script and raw results are attached.
Best regards,
Pavlo Golub
UNPATCHED PostgreSQL
Test 1: track='none' (clean baseline, no pg_stat_statements overhead)
- Run 1: 575.843 ms
- Run 2: 554.241 ms
- Run 3: 556.117 ms
Average: 562.07 ms
Test 2: track='all' (with pg_stat_statements tracking)
- Run 1: 725.412 ms
- Run 2: 713.809 ms
- Run 3: 718.276 ms
Average: 719.17 ms
---
PATCHED PostgreSQL (with stats_last_updated column)
Test 1: track='none' (clean baseline, no pg_stat_statements overhead)
- Run 1: 540.163 ms
- Run 2: 568.065 ms
- Run 3: 538.595 ms
Average: 548.95 ms
Test 2: track='all' (with pg_stat_statements + stats_last_updated)
- Run 1: 737.379 ms
- Run 2: 725.067 ms
- Run 3: 735.044 ms
Average: 732.50 ms
Attachments:
[text/plain] benchmark-raw-results.txt (669B, 2-benchmark-raw-results.txt)
download | inline:
UNPATCHED PostgreSQL
Test 1: track='none' (clean baseline, no pg_stat_statements overhead)
- Run 1: 575.843 ms
- Run 2: 554.241 ms
- Run 3: 556.117 ms
Average: 562.07 ms
Test 2: track='all' (with pg_stat_statements tracking)
- Run 1: 725.412 ms
- Run 2: 713.809 ms
- Run 3: 718.276 ms
Average: 719.17 ms
---
PATCHED PostgreSQL (with stats_last_updated column)
Test 1: track='none' (clean baseline, no pg_stat_statements overhead)
- Run 1: 540.163 ms
- Run 2: 568.065 ms
- Run 3: 538.595 ms
Average: 548.95 ms
Test 2: track='all' (with pg_stat_statements + stats_last_updated)
- Run 1: 737.379 ms
- Run 2: 725.067 ms
- Run 3: 735.044 ms
Average: 732.50 ms
[application/octet-stream] v4-0001-pg_stat_statements-Add-stats_last_updated-column.patch (18.1K, 3-v4-0001-pg_stat_statements-Add-stats_last_updated-column.patch)
download | inline diff:
From e0e2610caa63d3583cd96ad5ed521a5efd5546c8 Mon Sep 17 00:00:00 2001
From: Pavlo Golub <[email protected]>
Date: Thu, 5 Feb 2026 16:59:56 +0000
Subject: [PATCH] pg_stat_statements: Add stats_last_updated column (v4)
This patch adds a stats_last_updated timestamptz column to
pg_stat_statements, recording when each tracked statement was
most recently executed.
The motivation comes from monitoring tools that poll
pg_stat_statements regularly. With this timestamp, tools can
filter by 'stats_last_updated > last_poll_time' to fetch only
statements executed since the last poll, significantly reducing
storage overhead.
Changes from v3:
- Simplified implementation to use GetCurrentTimestamp() directly
- Removed complex calculation with GetCurrentStatementStartTimestamp()
and total_time computation (premature optimization)
- Benchmark testing shows no measurable overhead (<2% in synthetic tests)
Changes from v2:
- Added comprehensive benchmark testing (unpatched vs patched)
- Measured overhead: 13ns per statement (1.85% for 1M iteration test,
negligible for real queries >0.1ms)
Changes from v1:
- Rename column from last_executed to stats_last_updated (Christoph Berg)
- Move timestamp from Counters struct to pgssEntry for better semantics
- Place column at end of view to match stats_since naming convention
- Fixed whitespace errors
- Moved tests to entry_timestamp.sql (Sami Imseih)
- Updated PGSS_FILE_HEADER to handle structure change
Implementation:
The timestamp is captured using GetCurrentTimestamp() before acquiring
the spinlock, avoiding any syscall under lock. Benchmark testing shows
this overhead is negligible: ~13 nanoseconds per statement execution
in synthetic tests, and effectively unmeasurable (<0.02%) for any
real-world query.
Benchmark Results (Linux x86_64, 1M iterations PERFORM 1):
Unpatched track='all': 719.17ms aver age Patched track='all': 732.50ms average
Difference: +13.33ms (+1.85%), or 13ns per statement
For perspective: a 1ms query experiences 0.0013% overhead; a 100ms query
experiences 0.000013% overhead. This follows PostgreSQL's standard
practice of using GetCurrentTimestamp() for monitoring features.
The timestamp is stored in pgssEntry (not Counters) for semantic
correctness, and the column is placed at the end of the view following
'stats_since' naming conventions.
Addresses feedback from Sami Imseih, Christoph Berg, and Bertrand Drouvot.
---
contrib/pg_stat_statements/Makefile | 1 +
.../expected/entry_timestamp.out | 83 +++++++++++++++++++
contrib/pg_stat_statements/meson.build | 1 +
.../pg_stat_statements--1.13--1.14.sql | 79 ++++++++++++++++++
.../pg_stat_statements/pg_stat_statements.c | 44 +++++++++-
.../pg_stat_statements.control | 2 +-
.../sql/entry_timestamp.sql | 48 +++++++++++
doc/src/sgml/pgstatstatements.sgml | 13 +++
8 files changed, 267 insertions(+), 4 deletions(-)
create mode 100644 contrib/pg_stat_statements/pg_stat_statements--1.13--1.14.sql
diff --git a/contrib/pg_stat_statements/Makefile b/contrib/pg_stat_statements/Makefile
index c27e9529bb6..d7142f71cf7 100644
--- a/contrib/pg_stat_statements/Makefile
+++ b/contrib/pg_stat_statements/Makefile
@@ -7,6 +7,7 @@ OBJS = \
EXTENSION = pg_stat_statements
DATA = pg_stat_statements--1.4.sql \
+ pg_stat_statements--1.13--1.14.sql \
pg_stat_statements--1.12--1.13.sql \
pg_stat_statements--1.11--1.12.sql pg_stat_statements--1.10--1.11.sql \
pg_stat_statements--1.9--1.10.sql pg_stat_statements--1.8--1.9.sql \
diff --git a/contrib/pg_stat_statements/expected/entry_timestamp.out b/contrib/pg_stat_statements/expected/entry_timestamp.out
index a10c4be6bac..e90fa4f35e4 100644
--- a/contrib/pg_stat_statements/expected/entry_timestamp.out
+++ b/contrib/pg_stat_statements/expected/entry_timestamp.out
@@ -150,6 +150,89 @@ WHERE query LIKE '%STMTTS%';
2 | 1 | 2 | 0
(1 row)
+--
+-- stats_last_updated timestamp tests
+--
+SELECT 1 AS "STATS_UPD1";
+ STATS_UPD1
+------------
+ 1
+(1 row)
+
+SELECT now() AS ref_ts_upd1 \gset
+SELECT pg_sleep(0.1);
+ pg_sleep
+----------
+
+(1 row)
+
+SELECT 2 AS "STATS_UPD2";
+ STATS_UPD2
+------------
+ 2
+(1 row)
+
+SELECT now() AS ref_ts_upd2 \gset
+-- verify stats_last_updated is set and updated
+SELECT
+ query,
+ stats_last_updated IS NOT NULL as has_ts,
+ stats_last_updated >= :'ref_ts_upd1' as after_ref1,
+ stats_since <= stats_last_updated as after_stats_since
+FROM pg_stat_statements
+WHERE query LIKE '%STATS_UPD%'
+ORDER BY query COLLATE "C";
+ query | has_ts | after_ref1 | after_stats_since
+-------+--------+------------+-------------------
+(0 rows)
+
+-- execute again and verify update
+SELECT pg_sleep(0.1);
+ pg_sleep
+----------
+
+(1 row)
+
+SELECT 1 AS "STATS_UPD1";
+ STATS_UPD1
+------------
+ 1
+(1 row)
+
+SELECT now() AS ref_ts_upd3 \gset
+SELECT
+ query,
+ stats_last_updated >= :'ref_ts_upd3' as updated
+FROM pg_stat_statements
+WHERE query LIKE '%STATS_UPD1%';
+ query | updated
+-------+---------
+(0 rows)
+
+-- test filtering (monitoring use case)
+SELECT count(*) as filtered_count
+FROM pg_stat_statements
+WHERE stats_last_updated >= :'ref_ts_upd2'
+ AND query LIKE '%STATS_UPD%';
+ filtered_count
+----------------
+ 0
+(1 row)
+
+-- minmax reset should not affect stats_last_updated
+SELECT pg_stat_statements_reset(0, 0, queryid, true)
+FROM pg_stat_statements
+WHERE query LIKE '%STATS_UPD1%' \gset
+no rows returned for \gset
+SELECT
+ query,
+ stats_last_updated >= :'ref_ts_upd3' as ts_preserved
+FROM pg_stat_statements
+WHERE query LIKE '%STATS_UPD1%';
+ query | ts_preserved
+-------+--------------
+(0 rows)
+
-- Cleanup
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
t
diff --git a/contrib/pg_stat_statements/meson.build b/contrib/pg_stat_statements/meson.build
index 9d78cb88b7d..77148949c0d 100644
--- a/contrib/pg_stat_statements/meson.build
+++ b/contrib/pg_stat_statements/meson.build
@@ -21,6 +21,7 @@ contrib_targets += pg_stat_statements
install_data(
'pg_stat_statements.control',
'pg_stat_statements--1.4.sql',
+ 'pg_stat_statements--1.13--1.14.sql',
'pg_stat_statements--1.12--1.13.sql',
'pg_stat_statements--1.11--1.12.sql',
'pg_stat_statements--1.10--1.11.sql',
diff --git a/contrib/pg_stat_statements/pg_stat_statements--1.13--1.14.sql b/contrib/pg_stat_statements/pg_stat_statements--1.13--1.14.sql
new file mode 100644
index 00000000000..5aad9bf4a0b
--- /dev/null
+++ b/contrib/pg_stat_statements/pg_stat_statements--1.13--1.14.sql
@@ -0,0 +1,79 @@
+/* contrib/pg_stat_statements/pg_stat_statements--1.13--1.14.sql */
+
+-- complain if script is sourced in psql, rather than via ALTER EXTENSION
+\echo Use "ALTER EXTENSION pg_stat_statements UPDATE TO '1.14'" to load this file. \quit
+
+/* First we have to remove them from the extension */
+ALTER EXTENSION pg_stat_statements DROP VIEW pg_stat_statements;
+ALTER EXTENSION pg_stat_statements DROP FUNCTION pg_stat_statements(boolean);
+
+/* Then we can drop them */
+DROP VIEW pg_stat_statements;
+DROP FUNCTION pg_stat_statements(boolean);
+
+/* Now redefine */
+CREATE FUNCTION pg_stat_statements(IN showtext boolean,
+ OUT userid oid,
+ OUT dbid oid,
+ OUT toplevel bool,
+ OUT queryid bigint,
+ OUT query text,
+ OUT plans int8,
+ OUT total_plan_time float8,
+ OUT min_plan_time float8,
+ OUT max_plan_time float8,
+ OUT mean_plan_time float8,
+ OUT stddev_plan_time float8,
+ OUT calls int8,
+ OUT total_exec_time float8,
+ OUT min_exec_time float8,
+ OUT max_exec_time float8,
+ OUT mean_exec_time float8,
+ OUT stddev_exec_time float8,
+ OUT rows int8,
+ OUT shared_blks_hit int8,
+ OUT shared_blks_read int8,
+ OUT shared_blks_dirtied int8,
+ OUT shared_blks_written int8,
+ OUT local_blks_hit int8,
+ OUT local_blks_read int8,
+ OUT local_blks_dirtied int8,
+ OUT local_blks_written int8,
+ OUT temp_blks_read int8,
+ OUT temp_blks_written int8,
+ OUT shared_blk_read_time float8,
+ OUT shared_blk_write_time float8,
+ OUT local_blk_read_time float8,
+ OUT local_blk_write_time float8,
+ OUT temp_blk_read_time float8,
+ OUT temp_blk_write_time float8,
+ OUT wal_records int8,
+ OUT wal_fpi int8,
+ OUT wal_bytes numeric,
+ OUT wal_buffers_full int8,
+ OUT jit_functions int8,
+ OUT jit_generation_time float8,
+ OUT jit_inlining_count int8,
+ OUT jit_inlining_time float8,
+ OUT jit_optimization_count int8,
+ OUT jit_optimization_time float8,
+ OUT jit_emission_count int8,
+ OUT jit_emission_time float8,
+ OUT jit_deform_count int8,
+ OUT jit_deform_time float8,
+ OUT parallel_workers_to_launch int8,
+ OUT parallel_workers_launched int8,
+ OUT generic_plan_calls int8,
+ OUT custom_plan_calls int8,
+ OUT stats_since timestamp with time zone,
+ OUT minmax_stats_since timestamp with time zone,
+ OUT stats_last_updated timestamp with time zone
+)
+RETURNS SETOF record
+AS 'MODULE_PATHNAME', 'pg_stat_statements_1_14'
+LANGUAGE C STRICT VOLATILE PARALLEL SAFE;
+
+CREATE VIEW pg_stat_statements AS
+ SELECT * FROM pg_stat_statements(true);
+
+GRANT SELECT ON pg_stat_statements TO PUBLIC;
diff --git a/contrib/pg_stat_statements/pg_stat_statements.c b/contrib/pg_stat_statements/pg_stat_statements.c
index 4a427533bd8..cb68f939929 100644
--- a/contrib/pg_stat_statements/pg_stat_statements.c
+++ b/contrib/pg_stat_statements/pg_stat_statements.c
@@ -86,7 +86,7 @@ PG_MODULE_MAGIC_EXT(
#define PGSS_TEXT_FILE PG_STAT_TMP_DIR "/pgss_query_texts.stat"
/* Magic number identifying the stats file format */
-static const uint32 PGSS_FILE_HEADER = 0x20250731;
+static const uint32 PGSS_FILE_HEADER = 0x20260205;
/* PostgreSQL major version number, changes in which invalidate all entries */
static const uint32 PGSS_PG_MAJOR_VERSION = PG_VERSION_NUM / 100;
@@ -116,6 +116,7 @@ typedef enum pgssVersion
PGSS_V1_11,
PGSS_V1_12,
PGSS_V1_13,
+ PGSS_V1_14,
} pgssVersion;
typedef enum pgssStoreKind
@@ -240,6 +241,7 @@ typedef struct pgssEntry
int encoding; /* query text encoding */
TimestampTz stats_since; /* timestamp of entry allocation */
TimestampTz minmax_stats_since; /* timestamp of last min/max values reset */
+ TimestampTz stats_last_updated; /* timestamp of last stats update (statement end) */
slock_t mutex; /* protects the counters only */
} pgssEntry;
@@ -327,6 +329,7 @@ PG_FUNCTION_INFO_V1(pg_stat_statements_1_10);
PG_FUNCTION_INFO_V1(pg_stat_statements_1_11);
PG_FUNCTION_INFO_V1(pg_stat_statements_1_12);
PG_FUNCTION_INFO_V1(pg_stat_statements_1_13);
+PG_FUNCTION_INFO_V1(pg_stat_statements_1_14);
PG_FUNCTION_INFO_V1(pg_stat_statements);
PG_FUNCTION_INFO_V1(pg_stat_statements_info);
@@ -673,6 +676,7 @@ pgss_shmem_startup(void)
entry->counters = temp.counters;
entry->stats_since = temp.stats_since;
entry->minmax_stats_since = temp.minmax_stats_since;
+ entry->stats_last_updated = temp.stats_last_updated;
}
/* Read global statistics for pg_stat_statements */
@@ -1407,8 +1411,16 @@ pgss_store(const char *query, int64 queryId,
/* Increment the counts, except when jstate is not NULL */
if (!jstate)
{
+ TimestampTz stats_updated_at;
+
Assert(kind == PGSS_PLAN || kind == PGSS_EXEC);
+ /*
+ * Get current timestamp before acquiring spinlock to avoid holding
+ * the lock during syscall.
+ */
+ stats_updated_at = GetCurrentTimestamp();
+
/*
* Grab the spinlock while updating the counters (see comment about
* locking rules at the head of the file)
@@ -1513,6 +1525,9 @@ pgss_store(const char *query, int64 queryId,
else if (planOrigin == PLAN_STMT_CACHE_CUSTOM)
entry->counters.custom_plan_calls++;
+ /* Update the timestamp of the last stats update */
+ entry->stats_last_updated = stats_updated_at;
+
SpinLockRelease(&entry->mutex);
}
@@ -1581,7 +1596,8 @@ pg_stat_statements_reset(PG_FUNCTION_ARGS)
#define PG_STAT_STATEMENTS_COLS_V1_11 49
#define PG_STAT_STATEMENTS_COLS_V1_12 52
#define PG_STAT_STATEMENTS_COLS_V1_13 54
-#define PG_STAT_STATEMENTS_COLS 54 /* maximum of above */
+#define PG_STAT_STATEMENTS_COLS_V1_14 55
+#define PG_STAT_STATEMENTS_COLS 55 /* maximum of above */
/*
* Retrieve statement statistics.
@@ -1593,6 +1609,16 @@ pg_stat_statements_reset(PG_FUNCTION_ARGS)
* expected API version is identified by embedding it in the C name of the
* function. Unfortunately we weren't bright enough to do that for 1.1.
*/
+Datum
+pg_stat_statements_1_14(PG_FUNCTION_ARGS)
+{
+ bool showtext = PG_GETARG_BOOL(0);
+
+ pg_stat_statements_internal(fcinfo, PGSS_V1_14, showtext);
+
+ return (Datum) 0;
+}
+
Datum
pg_stat_statements_1_13(PG_FUNCTION_ARGS)
{
@@ -1765,6 +1791,10 @@ pg_stat_statements_internal(FunctionCallInfo fcinfo,
if (api_version != PGSS_V1_13)
elog(ERROR, "incorrect number of output arguments");
break;
+ case PG_STAT_STATEMENTS_COLS_V1_14:
+ if (api_version != PGSS_V1_14)
+ elog(ERROR, "incorrect number of output arguments");
+ break;
default:
elog(ERROR, "incorrect number of output arguments");
}
@@ -1840,6 +1870,7 @@ pg_stat_statements_internal(FunctionCallInfo fcinfo,
int64 queryid = entry->key.queryid;
TimestampTz stats_since;
TimestampTz minmax_stats_since;
+ TimestampTz stats_last_updated;
memset(values, 0, sizeof(values));
memset(nulls, 0, sizeof(nulls));
@@ -1908,11 +1939,12 @@ pg_stat_statements_internal(FunctionCallInfo fcinfo,
SpinLockRelease(&entry->mutex);
/*
- * The spinlock is not required when reading these two as they are
+ * The spinlock is not required when reading these three as they are
* always updated when holding pgss->lock exclusively.
*/
stats_since = entry->stats_since;
minmax_stats_since = entry->minmax_stats_since;
+ stats_last_updated = entry->stats_last_updated;
/* Skip entry if unexecuted (ie, it's a pending "sticky" entry) */
if (IS_STICKY(tmp))
@@ -2027,6 +2059,10 @@ pg_stat_statements_internal(FunctionCallInfo fcinfo,
values[i++] = TimestampTzGetDatum(stats_since);
values[i++] = TimestampTzGetDatum(minmax_stats_since);
}
+ if (api_version >= PGSS_V1_14)
+ {
+ values[i++] = TimestampTzGetDatum(stats_last_updated);
+ }
Assert(i == (api_version == PGSS_V1_0 ? PG_STAT_STATEMENTS_COLS_V1_0 :
api_version == PGSS_V1_1 ? PG_STAT_STATEMENTS_COLS_V1_1 :
@@ -2038,6 +2074,7 @@ pg_stat_statements_internal(FunctionCallInfo fcinfo,
api_version == PGSS_V1_11 ? PG_STAT_STATEMENTS_COLS_V1_11 :
api_version == PGSS_V1_12 ? PG_STAT_STATEMENTS_COLS_V1_12 :
api_version == PGSS_V1_13 ? PG_STAT_STATEMENTS_COLS_V1_13 :
+ api_version == PGSS_V1_14 ? PG_STAT_STATEMENTS_COLS_V1_14 :
-1 /* fail if you forget to update this assert */ ));
tuplestore_putvalues(rsinfo->setResult, rsinfo->setDesc, values, nulls);
@@ -2144,6 +2181,7 @@ entry_alloc(pgssHashKey *key, Size query_offset, int query_len, int encoding,
entry->encoding = encoding;
entry->stats_since = GetCurrentTimestamp();
entry->minmax_stats_since = entry->stats_since;
+ entry->stats_last_updated = entry->stats_since;
}
return entry;
diff --git a/contrib/pg_stat_statements/pg_stat_statements.control b/contrib/pg_stat_statements/pg_stat_statements.control
index 2eee0ceffa8..61ae41efc14 100644
--- a/contrib/pg_stat_statements/pg_stat_statements.control
+++ b/contrib/pg_stat_statements/pg_stat_statements.control
@@ -1,5 +1,5 @@
# pg_stat_statements extension
comment = 'track planning and execution statistics of all SQL statements executed'
-default_version = '1.13'
+default_version = '1.14'
module_pathname = '$libdir/pg_stat_statements'
relocatable = true
diff --git a/contrib/pg_stat_statements/sql/entry_timestamp.sql b/contrib/pg_stat_statements/sql/entry_timestamp.sql
index d6d3027ab4f..bae55fa7e22 100644
--- a/contrib/pg_stat_statements/sql/entry_timestamp.sql
+++ b/contrib/pg_stat_statements/sql/entry_timestamp.sql
@@ -110,5 +110,53 @@ SELECT
FROM pg_stat_statements
WHERE query LIKE '%STMTTS%';
+--
+-- stats_last_updated timestamp tests
+--
+
+SELECT 1 AS "STATS_UPD1";
+SELECT now() AS ref_ts_upd1 \gset
+SELECT pg_sleep(0.1);
+SELECT 2 AS "STATS_UPD2";
+SELECT now() AS ref_ts_upd2 \gset
+
+-- verify stats_last_updated is set and updated
+SELECT
+ query,
+ stats_last_updated IS NOT NULL as has_ts,
+ stats_last_updated >= :'ref_ts_upd1' as after_ref1,
+ stats_since <= stats_last_updated as after_stats_since
+FROM pg_stat_statements
+WHERE query LIKE '%STATS_UPD%'
+ORDER BY query COLLATE "C";
+
+-- execute again and verify update
+SELECT pg_sleep(0.1);
+SELECT 1 AS "STATS_UPD1";
+SELECT now() AS ref_ts_upd3 \gset
+
+SELECT
+ query,
+ stats_last_updated >= :'ref_ts_upd3' as updated
+FROM pg_stat_statements
+WHERE query LIKE '%STATS_UPD1%';
+
+-- test filtering (monitoring use case)
+SELECT count(*) as filtered_count
+FROM pg_stat_statements
+WHERE stats_last_updated >= :'ref_ts_upd2'
+ AND query LIKE '%STATS_UPD%';
+
+-- minmax reset should not affect stats_last_updated
+SELECT pg_stat_statements_reset(0, 0, queryid, true)
+FROM pg_stat_statements
+WHERE query LIKE '%STATS_UPD1%' \gset
+
+SELECT
+ query,
+ stats_last_updated >= :'ref_ts_upd3' as ts_preserved
+FROM pg_stat_statements
+WHERE query LIKE '%STATS_UPD1%';
+
-- Cleanup
SELECT pg_stat_statements_reset() IS NOT NULL AS t;
diff --git a/doc/src/sgml/pgstatstatements.sgml b/doc/src/sgml/pgstatstatements.sgml
index d753de5836e..835e5fadc08 100644
--- a/doc/src/sgml/pgstatstatements.sgml
+++ b/doc/src/sgml/pgstatstatements.sgml
@@ -593,6 +593,19 @@
<structfield>max_exec_time</structfield>)
</para></entry>
</row>
+
+ <row>
+ <entry role="catalog_table_entry"><para role="column_definition">
+ <structfield>stats_last_updated</structfield> <type>timestamp with time zone</type>
+ </para>
+ <para>
+ Time when statistics were last updated for this statement. This represents
+ the end time of the most recent execution that completed. For nested
+ statements (if <structfield>toplevel</structfield> is
+ <literal>false</literal>), this reflects when the top-level statement
+ completed.
+ </para></entry>
+ </row>
</tbody>
</tgroup>
</table>
--
2.52.0
[application/octet-stream] benchmark.sql (1.5K, 4-benchmark.sql)
download
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [PATCH] Add last_executed timestamp to pg_stat_statements
2025-12-11 11:31 Re[2]: [PATCH] Add last_executed timestamp to pg_stat_statements Pavlo Golub <[email protected]>
2025-12-11 16:35 ` Re: Re[2]: [PATCH] Add last_executed timestamp to pg_stat_statements Sami Imseih <[email protected]>
2026-02-06 15:47 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Sami Imseih <[email protected]>
2026-02-09 08:47 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Christoph Berg <[email protected]>
2026-02-09 16:51 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Sami Imseih <[email protected]>
2026-02-16 19:00 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Pavlo Golub <[email protected]>
@ 2026-02-16 22:06 ` Sami Imseih <[email protected]>
2026-02-17 08:30 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Pavlo Golub <[email protected]>
0 siblings, 1 reply; 10+ messages in thread
From: Sami Imseih @ 2026-02-16 22:06 UTC (permalink / raw)
To: Pavlo Golub <[email protected]>; +Cc: Christoph Berg <[email protected]>; Bertrand Drouvot <[email protected]>; [email protected] <[email protected]>
Hi,
> I simplified the implementation to use GetCurrentTimestamp() directly
> instead of calculating the timestamp from
I don't think it will be acceptable to add GetCurrentTimestamp() at the end of
every execution. We take extra measures to avoid such overhead in core, and
I don't think we should impose this on pg_stat_statements users as well.
For example, in c037471832e which tracks lastscan:
"
To make it easier to detect the last time a relation has been scanned, track
that time in each relation's pgstat entry. To minimize overhead a) the
timestamp is updated only when the backend pending stats entry is flushed to
shared stats b) the last transaction's stop timestamp is used as the
timestamp.
"
My opinion is still that using the last_start_time will be useful for monitoring
as you demonstrated [0], albeit with some complexity involved for the
monitoring client,
will be the best way and safest way forward.
Others may disagree.
> GetCurrentStatementStartTimestamp() + total_time. The previous optimization was
> premature, benchmark testing proves GetCurrentTimestamp() adds no
> measurable overhead.
I am not sure if this benchmark is enough to build confidence in this approach.
Workloads with nested queries and tack. 'all' are now paying an even heavier
cost.
Also, quickly looking at v4, you probably want to call GetCurrentTimestamp()
when kind == PGSS_EXEC only.
Assert(kind == PGSS_PLAN || kind == PGSS_EXEC);
+ /*
+ * Get current timestamp before acquiring spinlock to avoid holding
+ * the lock during syscall.
+ */
+ stats_updated_at = GetCurrentTimestamp();
+
/*
[0] https://www.postgresql.org/message-id/ema0100e49-522e-4b8f-9c25-9257af1f0793%40cybertec.at
--
Sami Imseih
Amazon Web Services (AWS)
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [PATCH] Add last_executed timestamp to pg_stat_statements
2025-12-11 11:31 Re[2]: [PATCH] Add last_executed timestamp to pg_stat_statements Pavlo Golub <[email protected]>
2025-12-11 16:35 ` Re: Re[2]: [PATCH] Add last_executed timestamp to pg_stat_statements Sami Imseih <[email protected]>
2026-02-06 15:47 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Sami Imseih <[email protected]>
2026-02-09 08:47 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Christoph Berg <[email protected]>
2026-02-09 16:51 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Sami Imseih <[email protected]>
2026-02-16 19:00 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Pavlo Golub <[email protected]>
2026-02-16 22:06 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Sami Imseih <[email protected]>
@ 2026-02-17 08:30 ` Pavlo Golub <[email protected]>
2026-02-17 23:59 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Sami Imseih <[email protected]>
0 siblings, 1 reply; 10+ messages in thread
From: Pavlo Golub @ 2026-02-17 08:30 UTC (permalink / raw)
To: Sami Imseih <[email protected]>; +Cc: Christoph Berg <[email protected]>; Bertrand Drouvot <[email protected]>; [email protected] <[email protected]>
Hi!
> I am not sure if this benchmark is enough to build confidence in this approach.
> Workloads with nested queries and tack. 'all' are now paying an even heavier
> cost.
I would love to see and test sql that will reveal the bigger overhead.
Do you have something specific on your mind? I'd love to share
results, we can use them later considering further updates to pgss.
>
> Also, quickly looking at v4, you probably want to call GetCurrentTimestamp()
> when kind == PGSS_EXEC only.
Fair enough! Thanks for noticing!
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [PATCH] Add last_executed timestamp to pg_stat_statements
2025-12-11 11:31 Re[2]: [PATCH] Add last_executed timestamp to pg_stat_statements Pavlo Golub <[email protected]>
2025-12-11 16:35 ` Re: Re[2]: [PATCH] Add last_executed timestamp to pg_stat_statements Sami Imseih <[email protected]>
2026-02-06 15:47 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Sami Imseih <[email protected]>
2026-02-09 08:47 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Christoph Berg <[email protected]>
2026-02-09 16:51 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Sami Imseih <[email protected]>
2026-02-16 19:00 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Pavlo Golub <[email protected]>
2026-02-16 22:06 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Sami Imseih <[email protected]>
2026-02-17 08:30 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Pavlo Golub <[email protected]>
@ 2026-02-17 23:59 ` Sami Imseih <[email protected]>
2026-03-30 16:42 ` Re[2]: [PATCH] Add last_executed timestamp to pg_stat_statements Pavlo Golub <[email protected]>
0 siblings, 1 reply; 10+ messages in thread
From: Sami Imseih @ 2026-02-17 23:59 UTC (permalink / raw)
To: Pavlo Golub <[email protected]>; +Cc: Christoph Berg <[email protected]>; Bertrand Drouvot <[email protected]>; [email protected] <[email protected]>
> > I am not sure if this benchmark is enough to build confidence in this approach.
> > Workloads with nested queries and tack. 'all' are now paying an even heavier
> > cost.
>
> I would love to see and test sql that will reveal the bigger overhead.
> Do you have something specific on your mind? I'd love to share
> results, we can use them later considering further updates to pgss.
Here is something I was experimenting with today. I ran 2
benchmarks; one on HEAD and one with GetCurrentTimestamp()
added when we are accumulating stats.
"""
/* Increment the counts, except when jstate is not NULL */
if (!jstate)
{
Assert(kind == PGSS_PLAN || kind == PGSS_EXEC);
GetCurrentTimestamp();
"""
The benchmak script is a series of "SELECT;"
# select_tx.sql
"""
begin;
select;
select;
select;
select;
select;
select;
select;
select;
select;
select;
select;
select;
select;
select;
select;
end;
"""
The benchmark was on my Ubuntu on EC2 c5a.12xlarge,
with default pg_stat_statements settings ( no plan tracking
and top tracking only ).
pgbench command:
```
pgbench -c48 -j16 -P1 -f select_tx.sql -T120
```
Results for 3 runs
## HEAD
tps = 29351.794589 (without initial connection time)
tps = 29470.287111 (without initial connection time)
tps = 29902.245458 (without initial connection time)
## with GetCurrentTimestamp()
tps = 28569.471891 (without initial connection time)
tps = 28013.051778 (without initial connection time)
tps = 28518.468843 (without initial connection time)
I see around 4-5% performance degradation.
--
Sami Imseih
Amazon Web Services (AWS)
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re[2]: [PATCH] Add last_executed timestamp to pg_stat_statements
2025-12-11 11:31 Re[2]: [PATCH] Add last_executed timestamp to pg_stat_statements Pavlo Golub <[email protected]>
2025-12-11 16:35 ` Re: Re[2]: [PATCH] Add last_executed timestamp to pg_stat_statements Sami Imseih <[email protected]>
2026-02-06 15:47 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Sami Imseih <[email protected]>
2026-02-09 08:47 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Christoph Berg <[email protected]>
2026-02-09 16:51 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Sami Imseih <[email protected]>
2026-02-16 19:00 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Pavlo Golub <[email protected]>
2026-02-16 22:06 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Sami Imseih <[email protected]>
2026-02-17 08:30 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Pavlo Golub <[email protected]>
2026-02-17 23:59 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Sami Imseih <[email protected]>
@ 2026-03-30 16:42 ` Pavlo Golub <[email protected]>
0 siblings, 0 replies; 10+ messages in thread
From: Pavlo Golub @ 2026-03-30 16:42 UTC (permalink / raw)
To: Sami Imseih <[email protected]>; +Cc: Christoph Berg <[email protected]>; Bertrand Drouvot <[email protected]>; [email protected] <[email protected]>
>
>Here is something I was experimenting with today. I ran 2
>benchmarks; one on HEAD and one with GetCurrentTimestamp()
>added when we are accumulating stats.
>
>"""
> /* Increment the counts, except when jstate is not NULL */
> if (!jstate)
> {
> Assert(kind == PGSS_PLAN || kind == PGSS_EXEC);
>
> GetCurrentTimestamp();
>"""
>
>The benchmak script is a series of "SELECT;"
>
># select_tx.sql
>"""
>begin;
>select;
>select;
>select;
>select;
>select;
>select;
>select;
>select;
>select;
>select;
>select;
>select;
>select;
>select;
>select;
>end;
>"""
>
>The benchmark was on my Ubuntu on EC2 c5a.12xlarge,
>with default pg_stat_statements settings ( no plan tracking
>and top tracking only ).
>
>pgbench command:
>```
>pgbench -c48 -j16 -P1 -f select_tx.sql -T120
>```
>
>Results for 3 runs
>
>## HEAD
>tps = 29351.794589 (without initial connection time)
>tps = 29470.287111 (without initial connection time)
>tps = 29902.245458 (without initial connection time)
>
>## with GetCurrentTimestamp()
>tps = 28569.471891 (without initial connection time)
>tps = 28013.051778 (without initial connection time)
>tps = 28518.468843 (without initial connection time)
>
>I see around 4-5% performance degradation.
Yeah, I can confirm. I have the same degradation on my local
environment.
Thanks for pointing this out!
I sent a new patch with a new column `last_execution_start`. I hope it
could make it before freeze. :)
https://www.postgresql.org/message-id/em5619eed4-8913-4ee8-a3cd-9f7101b06b6d%40cybertec.at
Best regardsz
^ permalink raw reply [nested|flat] 10+ messages in thread
end of thread, other threads:[~2026-03-30 16:42 UTC | newest]
Thread overview: 10+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-12-11 11:31 Re[2]: [PATCH] Add last_executed timestamp to pg_stat_statements Pavlo Golub <[email protected]>
2025-12-11 16:35 ` Sami Imseih <[email protected]>
2026-02-06 15:47 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Sami Imseih <[email protected]>
2026-02-09 08:47 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Christoph Berg <[email protected]>
2026-02-09 16:51 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Sami Imseih <[email protected]>
2026-02-16 19:00 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Pavlo Golub <[email protected]>
2026-02-16 22:06 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Sami Imseih <[email protected]>
2026-02-17 08:30 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Pavlo Golub <[email protected]>
2026-02-17 23:59 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Sami Imseih <[email protected]>
2026-03-30 16:42 ` Pavlo Golub <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox