Horton

Re: making EXPLAIN extensible

Sami Imseih <samimseih@gmail.com>

View thread
From: Sami Imseih <samimseih@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Jeff Davis <pgsql@j-davis.com>, Thom Brown <thom@linux.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-03-13T21:51:52Z
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.

Attachments

> The validation point is an interesting one.  I agree that we don't
> want the behavior to depend on the order in which options are
> written.

Here is what I applied on top of v6-0001 to correct this issue. Attaching it
as a text file only as Robert may have a different opinion on how to fix
this.

I felt the best way is to create another handler for registering a validation
function. This means we have to loop through the options list twice,
but I don't think that is a problem.

postgres=# explain (remote_plans, analyze) select * from t_r1;
ERROR:  EXPLAIN options REMOTE_PLANS and ANALYZE cannot be used together
postgres=# explain (analyze, remote_plans) select * from t_r1;
ERROR:  EXPLAIN options REMOTE_PLANS and ANALYZE cannot be used together

Regards,

Sami