From: Andrei Lepikhov <lepihov@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-bugs@lists.postgresql.org, Richard Guo <guofenglinux@gmail.com>
Cc: exclusion@gmail.com
Subject: Re: BUG #19037: Planner fails on estimating array length with "no relation entry" error
Date: Wed, 3 Sep 2025 10:56:39 +0200
Message-ID: <d7f2e3a5-ac97-4fbe-b4e2-3c8fd75b0e01@gmail.com> (raw)
In-Reply-To: <50858.1756590676@sss.pgh.pa.us>
References: <19037-3d1c7bb553c7ce84@postgresql.org>
<50858.1756590676@sss.pgh.pa.us>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: lepihov@gmail.com, tgl@sss.pgh.pa.us, guofenglinux@gmail.com, exclusion@gmail.com
Subject: Re: BUG #19037: Planner fails on estimating array length with "no relation entry" error
In-Reply-To: <d7f2e3a5-ac97-4fbe-b4e2-3c8fd75b0e01@gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox