Message-ID: <608a4886-6c60-0f9e-97d5-591256bd4150@gmail.com>
Date: Sat, 6 Jan 2024 12:00:01 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.2
Subject: Re: Wrong rows estimations with joins of CTEs slows queries by more
 than factor 500
Content-Language: en-US
To: Tom Lane <tgl@sss.pgh.pa.us>, 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>
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>
 <754093.1700250120@sss.pgh.pa.us>
From: Alexander Lakhin <exclusion@gmail.com>
In-Reply-To: <754093.1700250120@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/608a4886-6c60-0f9e-97d5-591256bd4150%40gmail.com>
Precedence: bulk

Hello Tom and Richard,

17.11.2023 22:42, Tom Lane wrote:
> 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.)

Please look at the following query:
CREATE TABLE t(i int);
INSERT INTO t VALUES (1);
VACUUM ANALYZE t;

WITH ir AS (INSERT INTO t VALUES (2) RETURNING i)
SELECT * FROM ir WHERE i = 2;

which produces ERROR:  no relation entry for relid 1
starting from f7816aec2.

Best regards,
Alexander