From: | Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Question about pull_up_sublinks_qual_recurse |
Date: | 2022-10-14 08:07:21 |
Message-ID: | CAKU4AWoJLhTaoeRX0_sMRy+8peCDxJR+mgm76Oy9nikqGnfyhw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
> Later we tried to pull up the EXISTS sublink to t1 OR t2 *separately*,
> since
> this subselect referenced to t1 *AND* t2, so we CAN'T pull up the
> sublink. I
> am thinking why we have to pull up it t1 OR t2 rather than JoinExpr(t1,
> t2),
> I think the latter one is better.
>
After some more self review, I find my proposal has the following side
effects.
select * from t1
where exists (select 1 from t2
where exists (select 1 from t3
where t3.c = t1.c)
and t2.a = t1.a);
In the above example, the innermost sublink will be joined with
SemiJoin (t1 t2) in the patched version, but joined with t1 in the current
master. However, even if we set the JoinTree with
SemiJoin(SemiJoin(t1 t2), t3), the join reorder functions can generate a
path which joins t1 with t3 first and then t2 still. So any hint about this
patch's self-review is welcome.
--
Best Regards
Andy Fan
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2022-10-14 08:24:41 | Re: Move backup-related code to xlogbackup.c/.h |
Previous Message | Simon Riggs | 2022-10-14 07:55:05 | Re: New docs chapter on Transaction Management and related changes |