Re: Re[2]: [PATCH] Add last_executed timestamp to pg_stat_statements - Mailing list pgsql-hackers

From Bertrand Drouvot
Subject Re: Re[2]: [PATCH] Add last_executed timestamp to pg_stat_statements
Date
Msg-id aYMKolTlvzenr4Pk@ip-10-97-1-34.eu-west-3.compute.internal
Whole thread Raw
In response to Re: Re[2]: [PATCH] Add last_executed timestamp to pg_stat_statements  (Sami Imseih <samimseih@gmail.com>)
List pgsql-hackers
Hi,

On Tue, Feb 03, 2026 at 08:37:31PM -0600, Sami Imseih wrote:
> > > I wonder if we can use GetCurrentStatementStartTimestamp()
> > > instead?
> >
> > The main use case for this column is being able to retrieve the stats
> > that were updated since the last time one was looking. That only works
> > if it's the statement end time, or else long-running statements
> > spanning more than one poll interval would be missed.
> 
> Sure, I get it is not perfect for the polling use-case due to the scenario
> you mention,  but I don't think it will be acceptable to call
> GetCurrentTimeStamp() at the end of every execution and especially
> with a SpinLock held.

I think the same, that would not match (lmgr/README):

"
* Spinlocks.  These are intended for *very* short-term locks.  If a lock
is to be held more than a few dozen instructions, or across any sort of
kernel call
"

Out of curiosity I looked for GetCurrentTimeStamp() calls while holding a spinlock
and found one in WalReceiverMain(). But I guess it's less of an issue since
it's only called when the walreceiver starts.

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Henson Choi
Date:
Subject: Re: Row pattern recognition
Next
From: Chao Li
Date:
Subject: pg_upgrade: fix memory leak in SLRU I/O code