Re: making EXPLAIN extensible

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jeff Davis <pgsql@j-davis.com>, Thom Brown <thom@linux.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-03-06T21:24:00Z
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 Thu, Mar 6, 2025 at 4:16 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I find a good deal of attraction in getting rid of the IDs and
> just using names.  Nor do I believe we need a hash table.
> (1) Surely there will not be so many extensions using this within a
> single EXPLAIN that a simple loop with strcmp()'s isn't good enough.
> (2) The IDs aren't free either; where will an extension keep the
> ID it assigned?  We're trying to move away from global variables.
>
> But, if you're convinced otherwise, the current design is OK.

Interesting. I hadn't even considered just iterating every time to
find the ID, but I agree with you that might be totally fine. As you
say, we're not expecting there to be many extensions here. I can try
coding that up and see how it looks (or you can, if you like).

I don't buy your second point, though. Our globals are probably going
to turn into thread-locals at some point, and we may want to do things
like bundle a bunch of related ones together in a struct, but I don't
see any real hope of getting rid of them altogether, and if we do, the
one integer you need to power this kind of extension will hardly be
the biggest problem.

-- 
Robert Haas
EDB: http://www.enterprisedb.com