public inbox for [email protected]
help / color / mirror / Atom feedRe[2]: [PATCH] Add last_executed timestamp to pg_stat_statements
3+ messages / 2 participants
[nested] [flat]
* Re[2]: [PATCH] Add last_executed timestamp to pg_stat_statements
@ 2026-02-06 11:19 Pavlo Golub <[email protected]>
2026-02-06 12:21 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Christoph Berg <[email protected]>
0 siblings, 1 reply; 3+ messages in thread
From: Pavlo Golub @ 2026-02-06 11:19 UTC (permalink / raw)
To: Christoph Berg <[email protected]>; +Cc: Sami Imseih <[email protected]>; Bertrand Drouvot <[email protected]>; [email protected] <[email protected]>
>
>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.
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: [PATCH] Add last_executed timestamp to pg_stat_statements
2026-02-06 11:19 Re[2]: [PATCH] Add last_executed timestamp to pg_stat_statements Pavlo Golub <[email protected]>
@ 2026-02-06 12:21 ` Christoph Berg <[email protected]>
2026-02-06 12:57 ` Re[2]: [PATCH] Add last_executed timestamp to pg_stat_statements Pavlo Golub <[email protected]>
0 siblings, 1 reply; 3+ messages in thread
From: Christoph Berg @ 2026-02-06 12:21 UTC (permalink / raw)
To: Pavlo Golub <[email protected]>; +Cc: Sami Imseih <[email protected]>; Bertrand Drouvot <[email protected]>; [email protected] <[email protected]>
Re: Pavlo Golub
> If we do
>
> 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.
Christoph
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re[2]: [PATCH] Add last_executed timestamp to pg_stat_statements
2026-02-06 11:19 Re[2]: [PATCH] Add last_executed timestamp to pg_stat_statements Pavlo Golub <[email protected]>
2026-02-06 12:21 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Christoph Berg <[email protected]>
@ 2026-02-06 12:57 ` Pavlo Golub <[email protected]>
0 siblings, 0 replies; 3+ messages in thread
From: Pavlo Golub @ 2026-02-06 12:57 UTC (permalink / raw)
To: Christoph Berg <[email protected]>; +Cc: Sami Imseih <[email protected]>; Bertrand Drouvot <[email protected]>; [email protected] <[email protected]>
>
>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.
>
>
>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.
+1
Maybe just move GetCurrentTimestamp outside of spin lock is engouh
already?
>
>
>Christoph
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2026-02-06 12:57 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-02-06 11:19 Re[2]: [PATCH] Add last_executed timestamp to pg_stat_statements Pavlo Golub <[email protected]>
2026-02-06 12:21 ` Re: [PATCH] Add last_executed timestamp to pg_stat_statements Christoph Berg <[email protected]>
2026-02-06 12:57 ` 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