Re: [HACKERS] Add support for tuple routing to foreign partitions
От | Etsuro Fujita |
---|---|
Тема | Re: [HACKERS] Add support for tuple routing to foreign partitions |
Дата | |
Msg-id | 5ABE33EF.1060308@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] Add support for tuple routing to foreign partitions (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>) |
Список | pgsql-hackers |
(2018/03/23 20:55), Etsuro Fujita wrote: > (2018/03/23 4:09), Robert Haas wrote: >> 1. It still doesn't work for COPY, because COPY isn't going to have a >> ModifyTableState. I really think it ought to be possible to come up >> with an API that can handle both INSERT and COPY; I don't think it >> should be necessary to have two different APIs for those two problems. >> Amit managed to do it for regular tables, and I don't really see a >> good reason why foreign tables need to be different. > > Maybe I'm missing something, but I think the proposed FDW API could be > used for the COPY case as well with some modifications to core. If so, > my question is: should we support COPY into foreign tables as well? I > think that if we support COPY tuple routing for foreign partitions, it > would be better to support direct COPY into foreign partitions as well. Done. >> 2. I previously asked why we couldn't use the existing APIs for this, >> and you gave me some answer, but I can't help noticing that >> postgresExecForeignRouting is an exact copy of >> postgresExecForeignInsert. Apparently, some code reuse is indeed >> possible here! Why not reuse the same function instead of calling a >> new one? If the answer is that planSlot might be NULL in this case, >> or something like that, then let's just document that. A needless >> proliferation of FDW APIs is really undesirable, as it raises the bar >> for every FDW author. > > You've got a point! I'll change the patch that way. Done. I modified the patch so that the existing API postgresExecForeignInsert is called as-is (ie, with the planSlot parameter) in the INSERT case and is called with that parameter set to NULL in the COPY case. So, I removed postgresExecForeignRouting and the postgres_fdw refactoring for that API. Also, I changed the names of the remaining new APIs to postgresBeginForeignInsert and postgresEndForeignInsert, which I think would be better because these are used not only for tuple routing but for directly copying into foreign tables. Also, I dropped partition_index from the parameter list for postgresBeginForeignInsert; I thought that it could be used for the FDW to access the partition info stored in mt_partition_tuple_routing for something in the case of tuple-routing, but I started to think that the FDW wouldn't need that in practice. >> However, I think that getting INSERT >> but not COPY, with bad performance, and with duplicated APIs, is >> moving more in the wrong direction than the right one. > > Will fix. Done. Attached is the new version of the patch. Patch foreign-routing-fdwapi-2.patch is created on top of patch postgres-fdw-refactoring-2.patch. (The former contains the bug-fix [1].) Any feedback is welcome! Best regards, Etsuro Fujita [1] https://www.postgresql.org/message-id/5ABA4074.1090500@lab.ntt.co.jp
Вложения
В списке pgsql-hackers по дате отправления: