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

From: "Pavlo Golub" <[email-masked]>
Date: Fri, 06 Feb 2026 11:19:26 +0000

>
>I still believe that storing execution start time is the wrong thing
>to do as it will miss all long-running statements. Consider this
>timeline:
>
>09:55 get all stats changed since 09:50
>       -> doesn't see the statement because it hasn't started yet
>09:57 start long-running statement
>10:00 get all stats changed since 09:55
>       -> doesn't see the statement because it's still running
>10:02 long-running statement terminates, storing 09:57 as timestamp
>10:05 get all stats changed since 10:00
>       -> doesn't see the statement because it's too old
>

Thanks for sharing this. I spent a sleepless night and it seems I found 
the solution for the issue.

If we do

   WHERE last_execution_start + max_exec_time * INTERVAL '1 ms' > NOW() - 
polling_interval

we will grab all long-running statements. The worst thing that might 
happen, if some query
has significant run time deviation, then we could grab it several times. 
But again this is far
better than re-fetching thousands of rows every time.

For short queries it will just work as expected. "Issues" might be only 
with long queries with
a high deviation longer than polling interval. But fetching one or two 
rows once in a while is not
a problem.

---

From: Christoph Berg <[email-masked]>
Date: Fri, 6 Feb 2026 13:21:09 +0100

Re: Pavlo Golub
>   WHERE last_execution_start + max_exec_time * INTERVAL '1 ms' > NOW() -

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.

Christoph

---

From: "Pavlo Golub" <[email-masked]>
Date: Fri, 06 Feb 2026 12:57:24 +0000

>Is this extra complexity worth one saved GetCurrentTimestamp()?

I'm not sure really. But I really need a new column in one way or 
another, so I can agree to whatever decision we'll make.
>would make this use case much nicer.
+1

Maybe just move GetCurrentTimestamp outside of spin lock is engouh 
already?