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
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 |