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
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) |