Re: inefficient/wrong plan cache mode selection for queries with partitioned tables (postgresql 17)

From: Maxim Boguk <maxim(dot)boguk(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, Andrei Lepikhov <lepihov(at)gmail(dot)com>, Pgsql Performance <pgsql-performance(at)lists(dot)postgresql(dot)org>
Subject: Re: inefficient/wrong plan cache mode selection for queries with partitioned tables (postgresql 17)
Date: 2025-05-12 17:55:07
Message-ID: CAK-MWwQWMK=d_Uzt63hstuYArAuB6Grv9sjYHMah1JXhgkxG3A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Mon, May 12, 2025 at 6:33 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Maxim Boguk <maxim(dot)boguk(at)gmail(dot)com> writes:
> > And the problem is that the cost of a custom plan ignores the cost of
> > planning itself (which is like 2x orders of magnitude worse than the cost
> > of real time partition pruning of a generic plan).
>
> False. The estimate is evidently pretty wrong, but it's not that
> there is no consideration at all. See around line 1370 in
> src/backend/utils/cache/plancache.c.
>
> regards, tom lane
>

Thank you.
Reading the code - probably the lowest hanging fruit is to make
'The current multiplier of 1000 * cpu_operator_cost' configurable in the
future versions.

PS: it's always nice to see when my ad-hoc idea (about N*nrelations as cost
planner estimate) is already implemented.

--
Maxim Boguk
Senior Postgresql DBA

Phone UA: +380 99 143 0000
Phone AU: +61 45 218 5678

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2025-05-12 18:07:54 Re: inefficient/wrong plan cache mode selection for queries with partitioned tables (postgresql 17)
Previous Message Andrei Lepikhov 2025-05-12 17:22:05 Re: inefficient/wrong plan cache mode selection for queries with partitioned tables (postgresql 17)