| 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
| 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 |