RE: Speeding up creating UPDATE/DELETE generic plan for partitionedtable into a lot
От | Tsunakawa, Takayuki |
---|---|
Тема | RE: Speeding up creating UPDATE/DELETE generic plan for partitionedtable into a lot |
Дата | |
Msg-id | 0A3221C70F24FB45833433255569204D1FB60AE5@G01JPEXMBYT05 обсуждение исходный текст |
Ответ на | Re: Speeding up creating UPDATE/DELETE generic plan for partitionedtable into a lot (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Ответы |
Re: Speeding up creating UPDATE/DELETE generic plan for partitionedtable into a lot
|
Список | pgsql-hackers |
From: Amit Langote [mailto:Langote_Amit_f8@lab.ntt.co.jp] > Maybe, we can invent new types of plans for queries on partitioned tables > that can be constructed by only looking at the parent relation. We'd need > new infrastructure before we can begin working on that though. For > example, until we had partitioned tables and the new partition pruning > module specialized for partitioned tables, we had to look at every child > to use constraint exclusion to emulate partition pruning. Starting in PG > 11, we now only look at the parent to perform pruning. To perform the > *whole planning* by just looking at the parent relation would require us > to build more infrastructure such that, for example, an appropriate scan > method for underlying partitions can be selected without having to open > the children. Although I may say the same thing as you, I think a natural idea would be to create a generic plan gradually. The startingsimple question is "why do we have to touch all partitions at first?" That is, can we behave like this: * PREPARE just creates an aggregation plan node (e.g. Append for SELECT, Update for UPDATE). It doesn't create any planfor particular partitions. Say, call this a parent generic plan node. * EXECUTE creates a generic plan for specific partitions if they don't exist yet, and attach them to the parent generic plannode. Regards Takayuki Tsunakawa
В списке pgsql-hackers по дате отправления: