From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Anthonin Bonnefoy <anthonin(dot)bonnefoy(at)datadoghq(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Add ALL_CANDIDATES option to EXPLAIN |
Date: | 2024-07-26 17:13:54 |
Message-ID: | 1743894.1722014034@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Anthonin Bonnefoy <anthonin(dot)bonnefoy(at)datadoghq(dot)com> writes:
> I have a prototype for an ALL_CANDIDATES option for EXPLAIN. The goal
> of this option is to print all plan candidates instead of only the
> cheapest plan. It will output the plans from the most expensive at the
> top to the cheapest.
This doesn't seem feasible at all to me. If we don't prune plans
fairly aggressively at lower plan levels, we'll have a combinatorial
explosion in the amount of work the planner has to do. Have you
tried this on even slightly complex plans --- say, a dozen-way join?
I do not think you'll like the runtime, the amount of memory consumed,
or the verboseness of the output. (I wonder how it interacts with
GEQO, too.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2024-07-26 17:16:43 | Re: Add ALL_CANDIDATES option to EXPLAIN |
Previous Message | Anthonin Bonnefoy | 2024-07-26 16:59:07 | Add ALL_CANDIDATES option to EXPLAIN |