Re: O(N^3) planning time in choose_plan_name() since 8c49a484e8e

From: Ayoub Kazar <ayoub(dot)kazar(at)data-bene(dot)io>
To: Manu <manuelreyesbravo(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Robert Haas <rhaas(at)postgresql(dot)org>
Subject: Re: O(N^3) planning time in choose_plan_name() since 8c49a484e8e
Date: 2026-11-01 02:31:18
Message-ID: 27d5038d-376c-4f4f-9253-56133791d5e3@data-bene.io
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 01/11/2026 01:55, Manu wrote:

> v4 keeps today's names: no existing expected output
> changes, and a 4000-arm UNION plans in 22 ms (v18 18.6 ms, master
> 16.9 s) with the same planner memory as master. If you would still
> rather have the single counter, that version is ready too.
Aside: The last test on:

+-- a name of NAMEDATALEN - 1 bytes, used twice
+EXPLAIN (COSTS OFF)
+WITH nnnnnnnnnnnnnnnnnnn

This isn't a concern anymore so we don't need this i think?

Also v3 had this test:

+EXPLAIN (COSTS OFF)
+SELECT (SELECT 1 WHERE random() >= 0),
+ (WITH expr_1 AS MATERIALIZED (SELECT 2 AS x) SELECT x FROM expr_1);
+ QUERY PLAN
+----------------------------------------------------------------
+ Result
+ InitPlan expr_1
+ -> Result
+ One-Time Filter: (random() >= '0'::double precision)
+ InitPlan expr_2
+ -> CTE Scan on expr_1
+ CTE expr_1_1
+ -> Result
+(8 rows)
+

I guess we should keep this for expr_1_1 case ...

Regards,
Ayoub

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message shihao zhong 2026-11-01 03:24:33 Re: First draft of PG 19 release notes
Previous Message shihao zhong 2026-11-01 01:05:27 Hash index corruption and CLOG lookup errors from checkpoint races