MIME-Version: 1.0
References: 
 <CAKU4AWoZksNZ4VR-fLTdwmiR91WU8qViDBNQKNwY=7iyo+uV0w@mail.gmail.com>
 <247851.1668293143@sss.pgh.pa.us>
 <CAKU4AWpp8aANvwU1ivjPtF3AakFjTf1jBm_OFmPSdCqizjBQLw@mail.gmail.com>
 <b9437269-0480-4016-91bf-61168f72bdd3@yandex.ru>
 <CAKU4AWrwggExWQ6mg7QGT59TVL6BGwBKbVn3ZQmmOAwOF3-w=g@mail.gmail.com>
 <602d6b44-c734-4f7f-8999-99b6cac9bf17@yandex.ru>
 <CAKU4AWphxS_QKEeUhSkt46_+7W8Y3ddr9q9roK4oWt0g2BZVmQ@mail.gmail.com>
 <00de47dd-7a38-4225-a47e-65a8ba6de8d3@yandex.ru>
In-Reply-To: <00de47dd-7a38-4225-a47e-65a8ba6de8d3@yandex.ru>
From: vignesh C <vignesh21@gmail.com>
Date: Fri, 26 Jan 2024 18:16:02 +0530
Message-ID: 
 <CALDaNm2ck2ykEpF+7LzT6c1GeXLn-YgDBwUh4VmQiZmeHEUetQ@mail.gmail.com>
Subject: Re: A new strategy for pull-up correlated ANY_SUBLINK
To: Alena Rybakina <lena.ribackina@yandex.ru>
Cc: Andy Fan <zhihui.fan1213@gmail.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>,
	Tom Lane <tgl@sss.pgh.pa.us>, Richard Guo <guofenglinux@gmail.com>,
	Andrey Lepikhov <a.lepikhov@postgrespro.ru>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CALDaNm2ck2ykEpF%2B7LzT6c1GeXLn-YgDBwUh4VmQiZmeHEUetQ%40mail.gmail.com>
Precedence: bulk

On Fri, 13 Oct 2023 at 14:09, Alena Rybakina <lena.ribackina@yandex.ru> wro=
te:
>
> On 13.10.2023 10:04, Andy Fan wrote:
>>
>> It seems to me that the expressions "=3D" and "IN" are equivalent here d=
ue to the fact that the aggregated subquery returns only one value, and the=
 result with the "IN" operation can be considered as the intersection of el=
ements on the left and right. In this query, we have some kind of set on th=
e left, among which there will be found or not only one element on the righ=
t.
>
>
> Yes, they are equivalent at the final result, but there are some
> differences at the execution level.  the '=3D' case will be transformed
> to a Subplan whose subPlanType is EXPR_SUBLINK, so if there
> is more than 1 rows is returned in the subplan, error will be raised.
>
> select * from tenk1 where
>   ten =3D  (select ten from tenk1 i where i.two =3D tenk1.two );
>
> ERROR:  more than one row returned by a subquery used as an expression
>
> However the IN case would not.
> select * from tenk1 where
>   ten =3D  (select ten from tenk1 i where i.two =3D tenk1.two ) is OK.
>
>
> I think the test case you added is not related to this feature. the
> difference is there even without the patch.  so I kept the code
> you changed, but not for the test  case.
>
> Yes, I understand and agree with you that we should delete the last queri=
es, except to one.
>
> The query below have a different result compared to master, and it is cor=
rect.
>
>
> Without your patch:
>
> explain (costs off)
> +SELECT * FROM tenk1 A LEFT JOIN tenk2 B
> ON B.hundred in (SELECT min(c.hundred) FROM tenk2 C WHERE c.odd =3D b.odd=
);
>                                  QUERY PLAN
> -------------------------------------------------------------------------=
----
>  Nested Loop Left Join
>    ->  Seq Scan on tenk1 a
>    ->  Materialize
>          ->  Seq Scan on tenk2 b
>                Filter: (SubPlan 2)
>                SubPlan 2
>                  ->  Result
>                        InitPlan 1 (returns $1)
>                          ->  Limit
>                                ->  Index Scan using tenk2_hundred on tenk=
2 c
>                                      Index Cond: (hundred IS NOT NULL)
>                                      Filter: (odd =3D b.odd)
> (12 rows)
>
>
> After your patch:
>
> postgres=3D# explain (costs off)
> SELECT * FROM tenk1 A LEFT JOIN tenk2 B
> ON B.hundred in (SELECT min(c.hundred) FROM tenk2 C WHERE c.odd =3D b.odd=
);
>
>                            QUERY PLAN
> --------------------------------------------------------------
>   Nested Loop Left Join
>     ->  Seq Scan on tenk1 a
>     ->  Materialize
>           ->  Nested Loop
>                 ->  Seq Scan on tenk2 b
>                 ->  Subquery Scan on "ANY_subquery"
>                       Filter: (b.hundred =3D "ANY_subquery".min)
>                       ->  Aggregate
>                             ->  Seq Scan on tenk2 c
>                                   Filter: (odd =3D b.odd)
> (10 rows)
>
>
>>> I took the liberty of adding this to your patch and added myself as rev=
iewer, if you don't mind.
>>
>> Sure, the patch after your modification looks better than the original.
>> I'm not sure how the test case around "because of got one row" is
>> relevant to the current changes.  After we reach to some agreement
>> on the above discussion, I think v4 is good for committer to review!
>>
>>
>> Thank you!) I am ready to discuss it.
>
>
> Actually I meant to discuss the "Unfortunately, I found a request..", loo=
ks
> we have reached an agreement there:)
>
> Yes, we have)

Hi Andy Fan,

If the changes of Alena are ok, can you merge the changes and post an
updated version so that CFBot can apply the patch and verify the
changes. As currently CFBot is trying to apply only Alena's changes
and failing with the following at [1]:
=3D=3D=3D Applying patches on top of PostgreSQL commit ID
fba2112b1569fd001a9e54dfdd73fd3cb8f16140 =3D=3D=3D
=3D=3D=3D applying patch ./pull-up.diff
patching file src/test/regress/expected/subselect.out
Hunk #1 succeeded at 1926 with fuzz 2 (offset -102 lines).
patching file src/test/regress/sql/subselect.sql
Hunk #1 FAILED at 1000.
1 out of 1 hunk FAILED -- saving rejects to file
src/test/regress/sql/subselect.sql.rej

[1] - http://cfbot.cputube.org/patch_46_4268.log

Regards,
Vignesh