Re: inefficient/wrong plan cache mode selection for queries with partitioned tables (postgresql 17) - Mailing list pgsql-performance

From David Rowley
Subject Re: inefficient/wrong plan cache mode selection for queries with partitioned tables (postgresql 17)
Date
Msg-id CAApHDvrduvaF6nN9ZQSfOdE0Na9SwPOkwYKn=Rb2a=Q9B72MAQ@mail.gmail.com
Whole thread Raw
List pgsql-performance
On Mon, 12 May 2025, 05:08 Andrei Lepikhov, <lepihov@gmail.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

pgsql-performance by date:

Previous
From: Craig Jackson
Date:
Subject: Re: Vacuum Questions
Next
From: Tom Lane
Date:
Subject: Re: inefficient/wrong plan cache mode selection for queries with partitioned tables (postgresql 17)