| From: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
|---|---|
| To: | torikoshia <torikoshia(at)oss(dot)nttdata(dot)com> |
| Cc: | Lukas Fittl <lukas(at)fittl(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Atsushi Torikoshi <torikoshia(dot)tech(at)gmail(dot)com>, samimseih(at)gmail(dot)com, destrex271(at)gmail(dot)com |
| Subject: | Re: RFC: Logging plan of the running query |
| Date: | 2026-09-18 09:46:00 |
| Message-ID: | 9a72f9d4-4afe-40d1-8208-7262d437e73d@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 08/09/2026 15:17, torikoshia wrote:
> On 2026-08-31 22:12, Andrei Lepikhov wrote:
>> What if an automation tool, triggered by certain events, requests a query plan
>> when a query goes over its quota? If we could identify the query plan in the
>> log, the tool could find the plan, decide whether to request it again, and
>> choose to either interrupt the query or let it run a bit longer.
>
> Would the following approach address your concern?
>
> - When pg_log_query_plan() is called, it generates a request ID, returns the ID
> to the caller, and passes it to the target backend.
> - The target backend includes the ID either in the resulting plan log or in a
> log message indicating that the request could not be completed.
Yes, I think this is a good way to explore.
I also see this code as an initial step toward a future full-fledged feature
that might need a shared memory structure for extra parameters. EXPLAIN by
itself, even in verbose mode, has limited benefits. In practice, the actual
number of rows and loops is way more useful. Because of this, I think the
feature should be designed so that future core changes or extensions can pass
some flags, such as 'interrupt query execution and calculate actual
instrumentation' or 'use specific explain settings'.
--
regards, Andrei Lepikhov,
pgEdge
| From | Date | Subject | |
|---|---|---|---|
| Next Message | shveta malik | 2026-09-18 09:58:38 | Re: Proposal: Conflict log history table for Logical Replication |
| Previous Message | Daniel Gustafsson | 2026-09-18 09:30:47 | Re: pg_regress: schedule multi-line test groups |