Date: Mon, 9 Feb 2026 09:47:07 +0100
From: Christoph Berg <myon@debian.org>
To: Pavlo Golub <pavlo.golub@cybertec.at>,
	Sami Imseih <samimseih@gmail.com>
Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>,
	"pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Subject: Re: [PATCH] Add last_executed timestamp to pg_stat_statements
Message-ID: <aYmfC5_vAZmaAAy9@msg.df7cb.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAA5RZ0vMW+0_6FYtFEaN-NAnk1sT2ucCUDJe0-xKwZriROV--A@mail.gmail.com>
 <emfe7f88ae-6f9a-469e-98f4-7eb9fbfddcfe@cybertec.at>
Archived-At: <https://www.postgresql.org/message-id/aYmfC5_vAZmaAAy9%40msg.df7cb.de>
Precedence: bulk

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