Re: speeding up planning with partitions
От | Peter Geoghegan |
---|---|
Тема | Re: speeding up planning with partitions |
Дата | |
Msg-id | CAH2-WznUbJx8OKohHcetyWQRy4LXEfbpTcAGFvc5K6i1BSG40w@mail.gmail.com обсуждение исходный текст |
Ответ на | speeding up planning with partitions (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Ответы |
Re: speeding up planning with partitions
|
Список | pgsql-hackers |
On Wed, Aug 29, 2018 at 5:06 AM, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote: > It is more or less well known that the planner doesn't perform well with > more than a few hundred partitions even when only a handful of partitions > are ultimately included in the plan. Situation has improved a bit in PG > 11 where we replaced the older method of pruning partitions one-by-one > using constraint exclusion with a much faster method that finds relevant > partitions by using partitioning metadata. However, we could only use it > for SELECT queries, because UPDATE/DELETE are handled by a completely > different code path, whose structure doesn't allow it to call the new > pruning module's functionality. Actually, not being able to use the new > pruning is not the only problem for UPDATE/DELETE, more on which further > below. This was a big problem for the SQL MERGE patch. I hope that this problem can be fixed. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: