Re: Planner picks n² query plan when available

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
Cc: Toto guyoyg <thomas(dot)bessou(at)hotmail(dot)fr>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Planner picks n² query plan when available
Date: 2024-11-21 13:52:46
Message-ID: 402024.1732197166@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> writes:
> On Thu, 21 Nov 2024 at 13:03, Toto guyoyg <thomas(dot)bessou(at)hotmail(dot)fr> wrote:
>>
>> Offending O(n²) query:

> I disagree with the O(n^2) claims.

I think these cases actually are O(n^2). But I'm finding it hard
to care. What we have here is a straightforward way to write a
query versus a much-less-straightforward way --- indeed, a way
that isn't even syntactically legal per the SQL standard.
The straightforward way is already well optimized, and no reason has
been given why the much-less-straightforward way should be considered
preferable. So I'm not seeing why we should put our finite
development resources into optimizing the much-less-straightforward
way.

>> 4. The EXPLAIN ANALYZE output shows that the planner always supposes that arrays are of size 10, instead of using the estimated sizes of subqueries they are created from, or actual size provided as argument.

It's a little disingenuous to complain about bad estimates with
this test methodology: the test tables are never vacuumed or
analyzed. And since they're temporary, there's no hope of
autovacuum curing that oversight. It's not clear that having
done that would improve anything in this particular case,
but it's certainly not helping.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey M. Borodin 2024-11-21 13:55:16 Re: Sample rate added to pg_stat_statements
Previous Message Sanjay Khatri 2024-11-21 13:50:23 Re: Windows 2016 server crashed after changes in Postgres 15.8 pgAdmin