Re: RFC: Logging plan of the running query

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

In response to

Browse pgsql-hackers by date

  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