RE: [POC] Fast COPY FROM command for the table with foreign partitions

Поиск
Список
Период
Сортировка
От tsunakawa.takay@fujitsu.com
Тема RE: [POC] Fast COPY FROM command for the table with foreign partitions
Дата
Msg-id TYAPR01MB29908A830017784F6E8A468FFE8E9@TYAPR01MB2990.jpnprd01.prod.outlook.com
обсуждение исходный текст
Ответ на RE: [POC] Fast COPY FROM command for the table with foreign partitions  ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>)
Ответы Re: [POC] Fast COPY FROM command for the table with foreign partitions  ("Andrey V. Lepikhov" <a.lepikhov@postgrespro.ru>)
Re: [POC] Fast COPY FROM command for the table with foreign partitions  (Justin Pryzby <pryzby@telsasoft.com>)
Список pgsql-hackers
From: tsunakawa.takay@fujitsu.com <tsunakawa.takay@fujitsu.com>
> From: Andrey Lepikhov <a.lepikhov@postgrespro.ru>
> > Of course, you can rebase it.
> 
> Thank you.  I might modify the basic part to incorporate my past proposal
> about improving the layering or modularity related to ri_useMultiInsert.  (But I
> may end up giving up due to lack of energy.)

Rebased to HEAD with the following modifications.  It passes make check in the top directory and contrib/postgres_fdw.

(1)
Placed and ordered new three FDW functions consistently among their documentation, declaration and definition.


(2)
Check if BeginForeignCopy is not NULL before calling it, because the documentation says it's not mandatory.


(3)
Changed the function name ExecSetRelationUsesMultiInsert() to ExecMultiInsertAllowed() because it does *not* set
anythingbut returns a boolean value to indicate whether the relation allows multi-insert.  I was bugged about this
function'sinterface and the use of ri_usesMultiInsert in ResultRelInfo.  I still feel a bit uneasy about things like
whetherthe function should really take the partition root (parent) argument, and whether it's a good design that
ri_usesMultiInsertis used for the executor functions to determine which of Begin/EndForeignCopy() or
Begin/EndForeignInsert()should be called.  I'm fine with COPY using executor, but it feels a bit uncomfortable for the
executorfunctions to be aware of COPY.
 


That said, with the reviews from some people and good performance results, I think this can be ready for committer.


> Also, I might defer working on the extended part (v9 0003 and 0004) and further
> separate them in a different thread, if it seems to take longer.

I reviewed them but haven't rebased them (it seems to take more labor.)
Andrey-san, could you tell us:

* Why is a separate FDW connection established for each COPY?  To avoid using the same FDW connection for multiple
foreigntable partitions in a single COPY run?
 

* In what kind of test did you get 2-4x performance gain?  COPY into many foreign table partitions where the input rows
areordered randomly enough that many rows don't accumulate in the COPY buffer?
 


Regards
Takayuki Tsunakawa



Вложения

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

Предыдущее
От: er@xs4all.nl
Дата:
Сообщение: Re: 2021-02-11 release announcement draft
Следующее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: parse mistake in ecpg connect string