Re: [HACKERS] Add support for tuple routing to foreign partitions

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Re: [HACKERS] Add support for tuple routing to foreign partitions
Дата
Msg-id f3edd72a-302a-2a6b-98f3-cc5c77c61d76@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: [HACKERS] Add support for tuple routing to foreign partitions  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Ответы Re: [HACKERS] Add support for tuple routing to foreign partitions  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Список pgsql-hackers
Fujita-san,

On 2017/12/12 21:21, Etsuro Fujita wrote:
> Hi Maksim,
> 
> (2017/12/12 17:57), Maksim Milyutin wrote:
>> Your patch already is not applied on master. Please rebase it.
> 
> Done.  Please find attached an updated version of the patch.

Thanks for sending the updated version of the patch.

I noticed that this patch introduces a partition_rels field in
ModifyTable, which contains the RT indexes of *all* leaf partitions in the
partition tree.  That means we now expand the partition inheritance tree
in the planner even in the INSERT case, simply because some of the leaf
partitions might be foreign tables which must be looked at by the planner.
 I'm somewhat concerned about the performance implications of that.  Now,
to insert even a single row into a partitioned table, which may not even
be routed to any of its foreign partitions, we are going to have to expand
the inheritance twice -- once by the planner to handle foreign partitions
and then by the executor when setting up the tuple routing information.

Is there any reason why we have to to things this way, beside the fact
that the PlanForeignModify() API appears to be callable from only within a
valid planner context?

Thanks,
Amit



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ildus Kurbangaliev
Дата:
Сообщение: Re: [HACKERS] Custom compression methods
Следующее
От: Aleksander Alekseev
Дата:
Сообщение: Re: GSoC 2018