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

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Andrei Lepikhov <lepihov(at)gmail(dot)com>
Cc: Maxim Boguk <maxim(dot)boguk(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 15:01:03
Message-ID: CAApHDvrduvaF6nN9ZQSfOdE0Na9SwPOkwYKn=Rb2a=Q9B72MAQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Mon, 12 May 2025, 05:08 Andrei Lepikhov, <lepihov(at)gmail(dot)com> wrote:

> Thanks for this puzzle!
> I suppose, in case generic planning is much faster than custom one,
> there are two candidates exist:
> 1. Touching the index during planning causes too much overhead - see
> get_actual_variable_range
> 2. You have a massive default_statistics_target for a table involved.
>

This is just an artifact of the fact that runtime pruning is not factored
into the costs. Note the cost of the generic plan. The plan_cache_mode GUC
is about the only way to overrule the choice to use the custom plan.

David

>

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Maxim Boguk 2025-05-12 15:18:43 Re: inefficient/wrong plan cache mode selection for queries with partitioned tables (postgresql 17)
Previous Message Maxim Boguk 2025-05-12 14:21:09 Re: inefficient/wrong plan cache mode selection for queries with partitioned tables (postgresql 17)