Re: BUG #17650: For the sixth time, the clipping function in the 120 partition table planning stage fails
От | Tom Lane |
---|---|
Тема | Re: BUG #17650: For the sixth time, the clipping function in the 120 partition table planning stage fails |
Дата | |
Msg-id | 2601909.1666101938@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #17650: For the sixth time, the clipping function in the 120 partition table planning stage fails (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #17650: For the sixth time, the clipping function in the 120 partition table planning stage fails
|
Список | pgsql-bugs |
PG Bug reporting form <noreply@postgresql.org> writes: > The clipping function of partition table cannot be carried out normally in > the planning stage. This looks like normal behavior to me: the sixth iteration is where the plan cache will try to see if a generic plan would be smarter to use than a custom one. Unsurprisingly, for a table partitioned as heavily as this one, it takes a little while even to construct a generic plan. Then it'll decide "nope, we'll stick to custom planning" and the subsequent executions take the same amount of time as before. You could override that with "set plan_cache_mode = force_custom_plan". But TBH my advice is to use fewer partitions. There are always going to be edge cases where the system has to consider all the partitions. If you're allergic to spending even half a dozen msec in the planner, you need to set up your tables in a way that doesn't require so much time when that happens. regards, tom lane
В списке pgsql-bugs по дате отправления: