Re: Pathify RHS unique-ification for semijoin planning - Mailing list pgsql-hackers

From Richard Guo
Subject Re: Pathify RHS unique-ification for semijoin planning
Date
Msg-id CAMbWs481ycmBaae1Q35eejzw44-GtWsEND9_ZQkSaY=VjVhxGQ@mail.gmail.com
Whole thread Raw
In response to Re: Pathify RHS unique-ification for semijoin planning  (Alexandra Wang <alexandra.wang.oss@gmail.com>)
Responses Re: Pathify RHS unique-ification for semijoin planning
List pgsql-hackers
On Fri, Aug 1, 2025 at 11:58 PM Alexandra Wang
<alexandra.wang.oss@gmail.com> wrote:
> While reviewing the code, the following diff concerns me:

>   if (joinrel->consider_parallel &&
> - save_jointype != JOIN_UNIQUE_OUTER &&
> - save_jointype != JOIN_FULL &&
> - save_jointype != JOIN_RIGHT &&
> - save_jointype != JOIN_RIGHT_ANTI &&
> + jointype != JOIN_FULL &&
> + jointype != JOIN_RIGHT &&
> + jointype != JOIN_RIGHT_ANTI &&
>   outerrel->partial_pathlist != NIL &&
>   bms_is_empty(joinrel->lateral_relids))
>
> What has changed that enabled JOIN_UNIQUE_OUTER to handle partial
> paths? Or is it no longer possible for the outer path to be partial?

It's the latter, as indicated by the Assert in create_unique_paths():

+       /*
+        * There shouldn't be any partial paths for the unique relation;
+        * otherwise, we won't be able to properly guarantee uniqueness.
+        */
+       Assert(unique_rel->partial_pathlist == NIL);

Thanks
Richard



pgsql-hackers by date:

Previous
From: jian he
Date:
Subject: Re: CAST(... ON DEFAULT) - WIP build on top of Error-Safe User Functions
Next
From: Richard Guo
Date:
Subject: Re: Pathify RHS unique-ification for semijoin planning