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
Re: [POC] Fast COPY FROM command for the table with foreign partitions |
Список | 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 по дате отправления: