Message-ID: <d7f2e3a5-ac97-4fbe-b4e2-3c8fd75b0e01@gmail.com>
Date: Wed, 3 Sep 2025 10:56:39 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: BUG #19037: Planner fails on estimating array length with "no
 relation entry" error
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-bugs@lists.postgresql.org, Richard Guo <guofenglinux@gmail.com>,
 exclusion@gmail.com
References: <19037-3d1c7bb553c7ce84@postgresql.org>
 <50858.1756590676@sss.pgh.pa.us>
Content-Language: en-US
From: Andrei Lepikhov <lepihov@gmail.com>
In-Reply-To: <50858.1756590676@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/d7f2e3a5-ac97-4fbe-b4e2-3c8fd75b0e01%40gmail.com>
Precedence: bulk

On 30/8/2025 23:51, Tom Lane wrote:
> PG Bug reporting form <noreply@postgresql.org> writes:
>> The following script:
> In some sense the "right" fix would be to do SubPlan generation
> later, when we have statistics available for the Vars of the
> parent query.  But that seems like a rather large task, and
> we'd surely not wish to back-patch the results.
I'd vote to go this direction in the next version.
Implementing memoisation of subplans to reduce the number of subplan 
evaluations, I encountered the same problem: the number of groups in the 
parameter set can't be estimated during subplan planning.
I resolved this issue by employing upper_paths_hook to decide the 
addition of Memoise nodes into subplans at the end of upper query planning.
But it is not an in-core solution and has a flaw with multi-level 
references.
So, it would be better to prepare as much PlannerInfo's info, as 
possible (base rels, maybe query tree?) before filling RelOptInfos with 
potential paths.

-- 
regards, Andrei Lepikhov