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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Manu <manuelreyesbravo(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Ayoub Kazar <ayoub(dot)kazar(at)data-bene(dot)io>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: O(N^3) planning time in choose_plan_name() since 8c49a484e8e
Date: 2026-11-06 14:41:47
Message-ID: CA+TgmoZbXofams7CeRoshD7fGdwua6V2mjmtTeBfstr1VowQYQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Nov 4, 2026 at 4:55 PM Manu <manuelreyesbravo(at)gmail(dot)com> wrote:
> With the 4000-arm UNION, planning takes 16.6 s on master, 22 ms with
> v5 or v6, and 19 ms on 18.6. With 4000 CTEs with different names it
> takes 153 ms on master and v5, 126 ms with v6 and 128 ms on 18.6.
> Below 32 names v6 only adds a pointer test or two per call. Small
> statements plan 2-4% slower with default builds, but the same
> (0.0%, 95% CI -0.9..+1.2) when both builds use -falign-functions=64,
> so I take that to be code layout.

Huh, that seems surprising. I expected the case with 4000 CTEs with
different names to be much worse. Why is the UNION case such a
disaster compared to everything else? I must be missing something
here. Of course, strcmp() on every list item is more expensive when
there's a prefix match, but I wouldn't expect that to make so much
difference.

--
Robert Haas
Databricks

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrei Lepikhov 2026-11-06 14:59:42 Re: Show 'Rows Removed by Filter' with two fractional digits in EXPLAIN
Previous Message Fujii Masao 2026-11-06 14:35:51 Re: file_fdw: Fix ANALYZE crashes with DEFAULT markers