Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ut5za-000c6L-TZ for pgsql-bugs@arkaria.postgresql.org; Mon, 01 Sep 2025 14:58:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1ut5yb-000NEo-MS for pgsql-bugs@arkaria.postgresql.org; Mon, 01 Sep 2025 14:57:46 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ut5yb-000NEf-EF for pgsql-bugs@lists.postgresql.org; Mon, 01 Sep 2025 14:57:45 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1ut5yY-0001Zh-17 for pgsql-bugs@lists.postgresql.org; Mon, 01 Sep 2025 14:57:45 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 581Evbc7346890; Mon, 1 Sep 2025 10:57:37 -0400 From: Tom Lane To: Richard Guo cc: exclusion@gmail.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #19037: Planner fails on estimating array length with "no relation entry" error In-reply-to: References: <19037-3d1c7bb553c7ce84@postgresql.org> <50858.1756590676@sss.pgh.pa.us> Comments: In-reply-to Richard Guo message dated "Mon, 01 Sep 2025 16:32:43 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <346888.1756738657.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Mon, 01 Sep 2025 10:57:37 -0400 Message-ID: <346889.1756738657@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Richard Guo writes: > On Sun, Aug 31, 2025 at 6:51 AM Tom Lane wrote: >> The most expedient solution is probably to hack examine_variable >> so that it doesn't fail if root->simple_rel_array isn't there yet. >> That seems mighty ugly though. > As an alternative, I wonder if we could pass root as NULL to > cost_subplan() when it's called from build_subplan(), and possibly > also from SS_process_ctes(). At those points, the root does not yet > contain enough information to safely consult statistics. Meanwhile, > cost_qual_eval() and the functions it calls are already well-equipped > to handle a NULL root. Good suggestion, that does seem more in keeping with established hacks^H^H^Hpractice. It'll need some commentary about why. I'm slightly tempted to do the dirty work in cost_subplan() itself, ie pass a NULL down to cost_qual_eval from there. Right now it doesn't matter, but maybe in future there would be some other safer use for the parent root in cost_subplan()? This approach would force the same behavior for the third caller of cost_subplan, SS_make_initplan_from_plan. But I don't think it matters there, since an initplan will by definition not be consulting anything from the parent plan. regards, tom lane