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
