Re: inefficient/wrong plan cache mode selection for queries with partitioned tables (postgresql 17)
От | Andrei Lepikhov |
---|---|
Тема | Re: inefficient/wrong plan cache mode selection for queries with partitioned tables (postgresql 17) |
Дата | |
Msg-id | b7da2330-1054-4bb8-939a-cb05d377f70f@gmail.com обсуждение исходный текст |
Ответ на | inefficient/wrong plan cache mode selection for queries with partitioned tables (postgresql 17) (Maxim Boguk <maxim.boguk@gmail.com>) |
Ответы |
Re: inefficient/wrong plan cache mode selection for queries with partitioned tables (postgresql 17)
|
Список | pgsql-performance |
On 5/12/25 13:49, Maxim Boguk wrote: > I suspect this situation should be quite common with queries over > partitioned tables (where planning time is usually quite a high). > > Any suggestions what could be done there outside of using > force_generic_plan for a particular db user (which will kill performance > in other queries for sure)? 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. So, to clarify the problem, may you provide EXPLAIN (without analyze) with BUFFERS ON ? Also, could you provide extra information on the statistics involved? For each column (I think created_at is the most important one), show the size of MCV and histogram arrays. -- regards, Andrei Lepikhov
В списке pgsql-performance по дате отправления: