On 2017/08/26 1:43, Robert Haas wrote:
On Sun, Aug 20, 2017 at 11:25 PM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp> wrote:
I agree, but I wonder if we ought to make it work first using the
existing APIs and then add these new APIs as an optimization.
I'm not sure that's a good idea because that once we support INSERT
tuple-routing for foreign partitions, we would have a workaround: INSERT
INTO partitioned_table SELECT * from data_table where data_table is a
foreign table defined for an input file using file_fdw.
That's true, but I don't see how it refutes the point I was trying to raise.
My concern is: the existing APIs can really work well for any FDW to do
COPY tuple-routing? I know the original version of the patch showed the
existing APIs would work well for postgres_fdw but nothing beyond. For
example: the original version made a dummy Query/Plan only containing a
leaf partition as its result relation, and passed it to
PlanForeignModify, IIRC. That would work well for postgres_fdw because
it doesn't look at the Query/Plan except the result relation, but might
not for other FDWs that look at more stuff of the given Query/Plan and
do something based on that information. Some FDW might check to see
whether the Plan is to do INSERT .. VALUES with a single VALUES sublist
or INSERT .. VALUES with multiple VALUES sublists, for optimizing remote
INSERT, for example.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
