From: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Maxim Boguk <maxim(dot)boguk(at)gmail(dot)com> |
Cc: | David Rowley <dgrowleyml(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-13 04:25:17 |
Message-ID: | a949410c-acd6-4a93-b49b-a050dd949671@gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 5/12/25 20:07, Tom Lane wrote:
> Maxim Boguk <maxim(dot)boguk(at)gmail(dot)com> writes:
>> Reading the code - probably the lowest hanging fruit is to make
>> 'The current multiplier of 1000 * cpu_operator_cost' configurable in the
>> future versions.
>
> I'm wondering whether we should try to make the planner not expend
> the effort in the first place, but leave partition pruning to the
> executor, at least in cases where it can determine that that will be
> possible.
Significant planning time is a sorting out lots of scan paths, applying
partition statistics etc. planner-stage partitioning reduces these
efforts drastically.
--
regards, Andrei Lepikhov
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2025-05-13 11:20:21 | Re: inefficient/wrong plan cache mode selection for queries with partitioned tables (postgresql 17) |
Previous Message | Tom Lane | 2025-05-12 18:07:54 | Re: inefficient/wrong plan cache mode selection for queries with partitioned tables (postgresql 17) |