Re: [PATCH] Add last_executed timestamp to pg_stat_statements

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Sami Imseih <samimseih(at)gmail(dot)com>
Cc: Pavlo Golub <pavlo(dot)golub(at)cybertec(dot)at>, Christoph Berg <myon(at)debian(dot)org>, 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-17 04:13:03
Message-ID: aZPqz7mqKl1sPkeK@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Feb 16, 2026 at 04:06:50PM -0600, Sami Imseih wrote:
>> I simplified the implementation to use GetCurrentTimestamp() directly
>> instead of calculating the timestamp from
>
> I don't think it will be acceptable to add GetCurrentTimestamp() at the end of
> every execution. We take extra measures to avoid such overhead in core, and
> I don't think we should impose this on pg_stat_statements users as well.

The posted v4 adds a GetCurrentTimestamp(), synonym of gettimeofday(),
for each call of pgss_store(). I suspect that this choice most likely
makes it a no-go on performance ground, and there have been complaints
about PGSS becoming noticeably slower with more fields added for the
last couple of releases. A timestamp call at reset or allocation is a
different matter, as it is capped naturally by a workload and the
number of entries configured. A timestamp call done each time an
entry is updated will make this code show higher in profiles.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2026-02-17 04:15:44 Re: Improve pg_sync_replication_slots() to wait for primary to advance
Previous Message Amit Kapila 2026-02-17 04:07:20 Re: Add into REFRESH PUBLICATION parameter exception_behaviour