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

Maxim Boguk <maxim.boguk@gmail.com>

From: Maxim Boguk <maxim.boguk@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: David Rowley <dgrowleyml@gmail.com>, Andrei Lepikhov <lepihov@gmail.com>, Pgsql Performance <pgsql-performance@lists.postgresql.org>
Date: 2025-05-12T17:55:07Z
Lists: pgsql-performance
On Mon, May 12, 2025 at 6:33 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Maxim Boguk <maxim.boguk@gmail.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