Horton

Re: making EXPLAIN extensible

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrei Lepikhov <lepihov@gmail.com>, Sami Imseih <samimseih@gmail.com>, Jeff Davis <pgsql@j-davis.com>, Thom Brown <thom@linux.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-03-27T11:29:51Z
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 Wed, Mar 26, 2025 at 10:40 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > -         ->  Index Scan using daucus_id_idx on daucus v2_2 (actual
> > rows=0.12 loops=8)
> > +         ->  Index Scan using daucus_id_idx on daucus v2_2 (actual
> > rows=0.13 loops=8)
>
> Even if this had not failed in the buildfarm, it would certainly
> have caused problems for somebody. We have a very strong rule
> that you *do not* make regression test results dependent on exact
> computed cost or rowcount values, because those are inherently
> platform-dependent.  I do not understand how you thought that
> pg_overexplain might be exempt from that problem.

Is this rule written down someplace?

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