Subject: Re[2]: [PATCH] Add last_executed timestamp to pg_stat_statements

From: "Pavlo Golub" <[email-masked]>
Date: Thu, 11 Dec 2025 11:31:39 +0000

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/[email-masked]
>[1] https://www.postgresql.org/message-id/03f82e6f-66a3-4c4d-935c-ea4d93871dc1%40gmail.com
>
>--
>Sami Imseih
>Amazon Web Services (AWS)

---

From: Sami Imseih <[email-masked]>
Date: Thu, 11 Dec 2025 10:35:41 -0600

> 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%40mail.gmail.com#beeebe3ca4a3dcda4ed625f7c15bb2d8

---

From: Sami Imseih <[email-masked]>
Date: Fri, 6 Feb 2026 09:47:07 -0600

> >   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.

---

From: Christoph Berg <[email-masked]>
Date: Mon, 9 Feb 2026 09:47:07 +0100

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

---

From: Sami Imseih <[email-masked]>
Date: Mon, 9 Feb 2026 10:51:30 -0600

> > We have total_time as an argument already! No kernel calls, sweet and easy!

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.

> > What I'm really getting at is separating these fields will open up

Maybe this is a bad use case. But I felt separating these 2 fields will
be more flexible.

> 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-masked]
[2] https://www.postgresql.org/message-id/[email-masked]

---

From: Pavlo Golub <[email-masked]>
Date: Mon, 16 Feb 2026 20:00:32 +0100

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

---

From: Sami Imseih <[email-masked]>
Date: Mon, 16 Feb 2026 16:06:50 -0600

Hi,

> 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.

> premature, benchmark testing proves GetCurrentTimestamp() adds no

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

---

From: Pavlo Golub <[email-masked]>
Date: Tue, 17 Feb 2026 09:30:26 +0100

Hi!

> Workloads with nested queries and tack. 'all' are now paying an even heavier

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.

> when kind == PGSS_EXEC only.

Fair enough! Thanks for noticing!

---

From: Sami Imseih <[email-masked]>
Date: Tue, 17 Feb 2026 17:59:12 -0600

> 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.

---

From: "Pavlo Golub" <[email-masked]>
Date: Mon, 30 Mar 2026 16:42:29 +0000

>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