| From: | Pavlo Golub <pavlo(dot)golub(at)cybertec(dot)at> |
|---|---|
| To: | Sami Imseih <samimseih(at)gmail(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Re[2]: [PATCH] pg_stat_statements: add last_execution_start column |
| Date: | 2026-04-14 16:15:50 |
| Message-ID: | CAK7ymcJpxfgu3q2XXwuuifrtkV6SqU9YbAt1=Ut_DdJ8wjS99A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>
> I think adding to queryDesc->EState just like we do for other fields
> that are consumed by pg_stat_statements, i.e. es_processed,
> es_parallel_workers_to_launch, etc. is the proper pattern.
Yeah, makes sense. Thanks.
> If we track the start time in queryDesc->EState, this will not be a
> problem. For utility
> statements, we can rely on a direct call to GetCurrentStatementStartTimestamp()
Thank you for the review. v3 addresses all concerns, I hope.
I switched from a bounded static array to statement start timestamp
stored in EState.
The field is set in pgss_ExecutorStart immediately after
standard_ExecutorStart creates the estate.
All pg_stat_statements regression tests pass (16/16).
Benchmark (16-vCPU, pgbench -c8 -j4 -T60):
master HEAD: ~4691 TPS (runs: 4849, 4588, 4635)
Patched v3: ~4744 TPS (runs: 4870, 4735, 4627)
Difference: ~1.1%
No measurable overhead.
The latest v3 patch attached.
>
> We also need to document that for toplevel = false statements, this
> execution_start time
> is that of the top level statement. I think that is acceptable.
Docs updated
>
> --
> Sami Imseih
> Amazon Web Services (AWS)
| Attachment | Content-Type | Size |
|---|---|---|
| v3-0001-pg_stat_statements-Add-last_execution_start-colum.patch | application/octet-stream | 23.7 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Melanie Plageman | 2026-04-14 16:21:57 | Re: Two issues leading to discrepancies in FSM data on the standby server |
| Previous Message | Kirill Reshke | 2026-04-14 16:08:04 | Re: GetCachedPlan() refactor: move execution lock acquisition out |