RE: [POC] Fast COPY FROM command for the table with foreign partitions - Mailing list pgsql-hackers

From tsunakawa.takay@fujitsu.com
Subject RE: [POC] Fast COPY FROM command for the table with foreign partitions
Date
Msg-id TYAPR01MB29908A830017784F6E8A468FFE8E9@TYAPR01MB2990.jpnprd01.prod.outlook.com
Whole thread Raw
In response to RE: [POC] Fast COPY FROM command for the table with foreign partitions  ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>)
Responses Re: [POC] Fast COPY FROM command for the table with foreign partitions
Re: [POC] Fast COPY FROM command for the table with foreign partitions
List 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



Attachment

pgsql-hackers by date:

Previous
From: er@xs4all.nl
Date:
Subject: Re: 2021-02-11 release announcement draft
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: parse mistake in ecpg connect string