Re: BUG #19037: Planner fails on estimating array length with "no relation entry" error

From: Andrei Lepikhov <lepihov(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org, Richard Guo <guofenglinux(at)gmail(dot)com>, exclusion(at)gmail(dot)com
Subject: Re: BUG #19037: Planner fails on estimating array length with "no relation entry" error
Date: 2025-09-03 08:56:39
Message-ID: d7f2e3a5-ac97-4fbe-b4e2-3c8fd75b0e01@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 30/8/2025 23:51, Tom Lane wrote:
> PG Bug reporting form <noreply(at)postgresql(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2025-09-03 10:19:17 BUG #19041: Logical replication locks wal processing
Previous Message Richard Guo 2025-09-03 08:08:28 Re: BUG #19037: Planner fails on estimating array length with "no relation entry" error