Re: making EXPLAIN extensible - Mailing list pgsql-hackers

On 4/3/2025 15:23, Robert Haas wrote:
> On Tue, Mar 4, 2025 at 8:56 AM Andrei Lepikhov <lepihov@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