Re: making EXPLAIN extensible

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, Thom Brown <thom(at)linux(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: making EXPLAIN extensible
Date: 2025-03-04 18:53:05
Message-ID: 5bbca514250c1f8ee45f08ada94184b0ae109fe9.camel@j-davis.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

+1 to the general idea, I didn't look at the patches yet.

On Fri, 2025-02-28 at 15:32 -0500, Robert Haas wrote:
> 1. It is much more verbose. I theorize that people will be unhappy
> about having to type EXPLAIN (pg_overexplain.range_table) rather than
> just EXPLAIN (range_table).

That was my first reaction.

> That's true. Of course, a lot depends on whether we end up with 3 or
> 5
> or 8 EXPLAIN extensions or more like 30 or 50 or 80. In the former
> case, the people writing those extensions will probably mostly know
> about each other and can just use different names.

I don't expect there to be zillions of extensions that only add new and
exciting explain options. Instead, it seems more likely that all
TableAM and CustomScan extensions will have 1-3 new explain options,
and that some of those might collide. For example, several may have a
EXPLAIN(PUSHDOWN) option that explains what work is being pushed down
into the TableAM/CustomScan.

In that case it's not even clear to me that a collision is a problem.
Would you really only want pushdown information from extension A, and
be upset that it also emits pushdown information from extension B?
Maybe we should just allow multiple extensions to use the same option
name?

Regards,
Jeff Davis

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2025-03-04 18:58:38 Re: scalability bottlenecks with (many) partitions (and more)
Previous Message Nathan Bossart 2025-03-04 18:36:21 Re: bogus error message for ALTER TABLE ALTER CONSTRAINT