Horton

Re: making EXPLAIN extensible

Matthias van de Meent <boekewurm+postgres@gmail.com>

View thread
From: Matthias van de Meent <boekewurm+postgres@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-03-03T14:14:35Z
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 Fri, 28 Feb 2025 at 20:26, Robert Haas <robertmhaas@gmail.com> wrote:
>
> Prior to PostgreSQL 10, EXPLAIN had just 2 options: VACUUM and
> ANALYZE.

I think you meant "some time prior to PostgreSQL 10".
PostgreSQL 9.0 had 5 options, of which COSTS, BUFFERS, and FORMAT were
newly added, so only before 9.0 we had 2 options.
PostgreSQL 9.2 then added TIMING on top of that, for a total of 6
options prior to PostgreSQL 10.

> It wouldn't make sense for core to have an EXPLAIN
> option whose whole purpose is to cater to the needs of some extension,
> so that made me think of providing some extensibility infrastructure.

+1, Neon would greatly appreciate infrastructure to allow extending EXPLAIN.

> 0001 allows a loadable module to register new EXPLAIN options.
> Currently, EXPLAIN (FUNGUS) will error out, but if you want to make it
> work, this patch is for you. This patch also allows you to stash some
> state related to your new option, or options, in the ExplainState.
> Core options have hard-coded structure members; e.g. EXPLAIN (BUFFERS)
> sets es->buffers. If you add EXPLAIN (FUNGUS), there won't be an
> es->fungus, but you can get about the same effect using the new
> facilities provided here.

Does this work with parallel workers' stats?
I can't seem to figure out whether or where parallel workers would
pass through their extended explain statistics, mostly because of the
per-backend nature of ID generation making the pointers of
ExplainState->extension_state unshareable.

Kind regards,

Matthias van de Meent