On 4/3/2025 15:23, Robert Haas wrote:
On Tue, Mar 4, 2025 at 8:56 AM Andrei Lepikhov <lepi...@gmail.com> wrote:
Passing through the patches, I would say that changing the order of 0001
and 0002 would make them more independent.
Hmm, I thought this order made sense, but I could reorder them if
there's some compelling reason to do so. If there's no particularly
compelling reason, it would be less work to commit them in this order.
I have no compelling reason except avoiding adding/removing explain.h
into the head of auto_explain.c and file_fdw.c
Also, I'm ok with the floating order of extension messages in the
explain output. We get used to living with dependencies on extension
load order (pg_stat_statements quite annoyingly impacts queryid, for
example), and this issue should be solved generally, in my opinion.
I've often thought that the solution to this class of problems could
be to have extensions not manipulate a hook variable directly, but
instead call a function to which they pass their callback function and
an integer priority. Then we could call hook functions in priority
order. One difficulty is that this requires extension authors to agree
on what the priority order should be. In some cases that might not be
too hard, but it isn't apparent how it would work here.
IMHO, it's reasonable for the author of an EXPLAIN extension to say
"well, I see Robert already created an extension with an option called
DEBUG, so I will name my option TROUBLESHOOT," or something of that
sort. But if Robert gave the DEBUG hook priority 50, should I also
give my hook priority 50, or should I make it 40 or 25 or 1 or 100 or
what? Even if I know about all of the other extensions it's not really
clear what I should do. Actually, in this case, it feels like it would
be better if the user could control the ordering somehow, but I feel
like that might be over-engineering.
I think the same way. It would be clearer for an observer to have a
dependency on load order everywhere than different orders in different
places with no strong guarantees.
Also, I think this feature is quite close to the discussion on the
possibility of adding an extensible list field into Query, PlanState,
Plan, etc. nodes to let extensions gather and transfer some additional
data starting with the first 'analyze' hook up to the end of execution.
For example, in solving user issues, I frequently need to know
predictions on the number of groups in Memoize, IncrementalSort and some
other nodes. Such extensibility could allow an extension to gather such
internal data during the planning stage and show it in the explain
without any changes in the core!
--
regards, Andrei Lepikhov
