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-19T20:51:53Z
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.

> 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?

--
Sami Imseih
Amazon Web Services (AWS)