Re: Question about pull_up_sublinks_qual_recurse

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

In response to

Responses

Browse pgsql-hackers by date

  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