| From: | Christoph Berg <myon(at)debian(dot)org> |
|---|---|
| To: | Pavlo Golub <pavlo(dot)golub(at)cybertec(dot)at>, Sami Imseih <samimseih(at)gmail(dot)com> |
| Cc: | 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-09 08:47:07 |
| Message-ID: | aYmfC5_vAZmaAAy9@msg.df7cb.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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 | Date | Subject | |
|---|---|---|---|
| Next Message | Chao Li | 2026-02-09 09:21:17 | Fix a bug in extension_file_exists() |
| Previous Message | Andrew Kim | 2026-02-09 08:42:06 | Re: Proposal for enabling auto-vectorization for checksum calculations |