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  (David Rowley <david.rowley@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: plpgsql plugin - stmt_beg/end is not called for top level blockof statements
Следующее
От: Mitar
Дата:
Сообщение: Re: Feature: triggers on materialized views