From: tsunakawa.ta...@fujitsu.com <tsunakawa.ta...@fujitsu.com> > From: Andrey Lepikhov <a.lepik...@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 anything but returns a boolean value to indicate whether the relation allows multi-insert. I was bugged about this function's interface and the use of ri_usesMultiInsert in ResultRelInfo. I still feel a bit uneasy about things like whether the function should really take the partition root (parent) argument, and whether it's a good design that ri_usesMultiInsert is 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 executor functions 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 foreign table 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 are ordered randomly enough that many rows don't accumulate in the COPY buffer? Regards Takayuki Tsunakawa
v14-0001-Fast-COPY-FROM-into-the-foreign-or-sharded-table.patch
Description: v14-0001-Fast-COPY-FROM-into-the-foreign-or-sharded-table.patch
