| 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[2]: [PATCH] pg_stat_statements: add last_execution_start column |
| Date: | 2026-04-01 12:49:05 |
| Message-ID: | em32f624bf-881e-4c4b-af7d-ddfa0fd21cee@cybertec.at |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hey!
>Hi,
>
>It would be really great to get this field in, but I think the current
>implementation still suffers from the same issue that is mentioned
>here [1]. We cannot rely on GetCurrentStatementStartTimestamp()
>in-line because ExecutorEnd is deferred to the next execution in the
>case of extended query protocol.
Oh, I completely missed this fact from the previous thread! Thanks for
pointing this out!
>I think we need to add it to track the
>start timestamp in queryDesc. What do you think?
I agree this might be the proper way to go but I don't want to touch
core functionality
in this patch. I'm afraid it could lead to even more problems with
accepting.
Please, find my new patch that addresses the issue. It captures the
statement start timestamp
at ExecutorStart and then save it to per-nesting-level array to write it
later in ExecutorEnd.
I set the max nesting level to 64, just because it feels right. I have
no other motivation here.
For even deeper statements it will fall back to direct
GetCurrentStatementStartTimestamp().
I added new regression test based on your example.
Benchmark is still OK (16-vCPU, pgbench -c8 -j4 -T60, explicit
transactions with
15 SELECT statements each):
master HEAD: ~4356 TPS (runs: 4089, 4308, 4672)
patched v2: ~4383 TPS (runs: 4226, 4382, 4541)
difference: ~0.6%
How do you feel about it?
Best regards,
Pavlo Golub
| Attachment | Content-Type | Size |
|---|---|---|
| v2-0001-pg_stat_statements-Add-last_execution_start-colum.patch | application/octet-stream | 23.5 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | jian he | 2026-04-01 13:12:54 | Re: refactor ExecInitPartitionInfo |
| Previous Message | Laurenz Albe | 2026-04-01 12:47:19 | Re: Online PostgreSQL version() updates |