Horton

Re: making EXPLAIN extensible

Sami Imseih <samimseih@gmail.com>

View thread
From: Sami Imseih <samimseih@gmail.com>
To: Andrei Lepikhov <lepihov@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Jeff Davis <pgsql@j-davis.com>, Thom Brown <thom@linux.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-03-20T14:04:08Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. pg_overexplain: Use PG_MODULE_MAGIC_EXT.

  2. pg_overexplain: Call previous hooks as appropriate.

  3. pg_overexplain: Additional EXPLAIN options for debugging.

  4. Add an additional hook for EXPLAIN option validation.

  5. Add some new hooks so extensions can add details to EXPLAIN.

  6. Make it possible for loadable modules to add EXPLAIN options.

>
> On 19/3/2025 21:51, Sami Imseih wrote:
> >> Why do you think this hook is not redundant?
> > what is it redundant with?
> >
> >> It would be better to add the parameter "type: EXPLAIN_ONLY |
> >> ANALYZE_ONLY | BOTH" to the RegisterExtensionExplainOption() routine.
> >> This value will be saved inside the ExplainExtensionOption structure and
> >> processed by the core inside the ParseExplainOptionList.
> >
> > hmm, IIUC, what you are describing is flag that will be limited to
> > only check if an option can be used with EXPLAIN_ONLY, ANALYZE_ONLY
> > or both. But what about if I have a case to check against between other
> > extension options? let's say ExtensionAOptionA and ExtensionAoptionB.
> > How would that work with the way you are suggesting?
> That makes sense. It would be more effective to include the meaningful
> example in Robert's extension for v7-0001.

While it will be good to provide an example in v7-0001, I can't see
any of the pg_overexplain options needing such validation.

> I'm sorry, I was confused; previously, the difficulties faced by
> extension developers were always attributed to him (refer to the
> discussion on the selectivity hook). However, now you're introducing a
> hook for a trivial operation that could simply be resolved at the end of
> execution within a per-node hook with tiny inconsistency in output. I'm
> pleased to see a change in the narrative.

I think you are referring to the idea to put a hook before
/* in text format, the first line ends here */

After considering the comments, I do see that was not a good proposal. You are
correct, and the per-node hook is enough.


--
Sami Imseih
Amazon Web Services (AWS)