| From: | Christoph Berg <myon(at)debian(dot)org> |
|---|---|
| To: | Pavlo Golub <pavlo(dot)golub(at)cybertec(dot)at> |
| Cc: | Sami Imseih <samimseih(at)gmail(dot)com>, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [PATCH] Add last_executed timestamp to pg_stat_statements |
| Date: | 2026-02-06 10:52:18 |
| Message-ID: | aYXH4hkFc_2xOa8t@msg.df7cb.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Re: Pavlo Golub
> > I still wonder if "stats_last_updated" is a good name here. What about
> > "last_execution_start", since that is exactly what this timestamp is.
>
> Yeah, sounds better really. Thanks
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
Christoph
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2026-02-06 10:59:51 | Re: Concerns regarding code in pgstat_backend.c |
| Previous Message | Alexandre Felipe | 2026-02-06 10:52:01 | Re: New access method for b-tree. |