From: Tom Lane <tgl@sss.pgh.pa.us>
To: Richard Guo <guofenglinux@gmail.com>
cc: Jian Guo <gjian@vmware.com>, Tomas Vondra <tomas.vondra@enterprisedb.com>,
        Hans Buschmann <buschmann@nidsa.net>,
        "pgsql-hackers@lists.postgresql.org"
 <pgsql-hackers@lists.postgresql.org>,
        Zhenghua Lyu <zlyu@vmware.com>
Subject: Re: Wrong rows estimations with joins of CTEs slows queries by more
 than factor 500
In-reply-to: 
 <CAMbWs49eVQMgfR-KNALJB15RR5r-zjNtNWnB0j5S=j40gtu1Jg@mail.gmail.com>
References: <4504e67078d648cdac3651b2960da6e7@nidsa.net>
 <SN6PR05MB5199BB4BB8C982BB519B6660C417A@SN6PR05MB5199.namprd05.prod.outlook.com>
 <46a7d950-7ca7-8ab9-76dd-f0bc7611c609@enterprisedb.com>
 <SN6PR05MB5199C0095508555B7D8D0D23C41EA@SN6PR05MB5199.namprd05.prod.outlook.com>
 <891440.1699483495@sss.pgh.pa.us>
 <CAMbWs4-W_81Q3ff1Bk3NU_ChRzOJK0njAoJanW-kXnPF0wjd1Q@mail.gmail.com>
 <414317.1700158568@sss.pgh.pa.us>
 <CAMbWs48Z_PvveOeankGA69=V=fqogusRKGVPBUGfYC0zDo1WPA@mail.gmail.com>
 <482957.1700192299@sss.pgh.pa.us>
 <CAMbWs49eVQMgfR-KNALJB15RR5r-zjNtNWnB0j5S=j40gtu1Jg@mail.gmail.com>
Comments: In-reply-to Richard Guo <guofenglinux@gmail.com>
	message dated "Fri, 17 Nov 2023 14:41:12 +0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <754092.1700250120.1@sss.pgh.pa.us>
Content-Transfer-Encoding: 8bit
Date: Fri, 17 Nov 2023 14:42:00 -0500
Message-ID: <754093.1700250120@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/754093.1700250120%40sss.pgh.pa.us>
Precedence: bulk

Richard Guo <guofenglinux@gmail.com> writes:
> On Fri, Nov 17, 2023 at 11:38 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> That line of argument also leads to the conclusion that it'd be
>> okay to expose info about the ordering of the CTE result to the
>> upper planner.  This patch doesn't do that, and I'm not sufficiently
>> excited about the issue to go write some code.  But if someone else
>> does, I think we shouldn't exclude doing it on the grounds of wanting
>> to preserve an optimization fence.  The fence is sort of one-way
>> in this line of thinking: information can propagate up to the outer
>> planner level, but not down into the CTE plan.

> Exactly!  Thanks for the detailed explanation.

OK.  I pushed the patch after a bit more review: we can simplify
things some more by using the subroot->parse querytree for all
tests.  After the previous refactoring, it wasn't buying us anything
to do some initial tests with the raw querytree.  (The original
idea of that, I believe, was to avoid doing find_base_rel if we
could; but now that's not helpful.)

			regards, tom lane