On Fri, Jun 5, 2026 at 4:56 PM Yugo Nagata <[email protected]> wrote:
>
> Hi,
>
> While looking at alternatives.out in the regression test of pg_plan_advice,
> I was a bit confused because there are exists_1 and exists_2 in the generated
> plan advice even though the query contains only one EXISTS.
>
>   EXPLAIN (COSTS OFF, PLAN_ADVICE)
>   SELECT * FROM alt_t1
>   WHERE EXISTS (SELECT 1 FROM alt_t2 WHERE alt_t2.a = alt_t1.a) OR alt_t1.a < 
> 0;
>                               QUERY PLAN
>   -------------------------------------------------------------------
>    Seq Scan on alt_t1
>      Filter: ((ANY (a = (hashed SubPlan exists_2).col1)) OR (a < 0))
>      SubPlan exists_2
>        ->  Seq Scan on alt_t2
>    Generated Plan Advice:
>      SEQ_SCAN(alt_t1 alt_t2@exists_2)
>      NO_GATHER(alt_t1 alt_t2@exists_2)
>      DO_NOT_SCAN(alt_t2@exists_1)
>   (8 rows)
>
> I realized that when an EXISTS is simple, it is converted into an additional
> ANY subplan. However, it seems slightly confusing that the prefix "exists_"
> is the same as the original EXISTS subplan, especially when using
> pg_plan_advice to control the plan.
>
> I am wondering whether it might be worth renaming the subplan to something
> like "exists_to_any", to make it clearer that it is an ANY subplan converted
> from EXISTS rather than the original EXISTS. I’ve attached a patch in this 
> direction.
>
> What do you think?

Agreed.

Using the same "exists_*" prefix for both the original EXISTS subplan and
the EXISTS-to-ANY converted alternative is confusing, especially for
pg_plan_advice where the subplan name is user-visible and used when
specifying advice.

Renaming the converted subplan to "exists_to_any_*" makes the EXPLAIN
output and generated advice easier to understand without changing planner
behavior, so this seems like a reasonable improvement.

Regards,

-- 
Fujii Masao


Reply via email to