(2018/02/02 19:33), Etsuro Fujita wrote:
> (2018/01/25 23:33), Stephen Frost wrote:
>> I'm afraid a good bit of this patch is now failing to apply. I don't
>> have much else to say except to echo the performance concern that Amit
>> Langote raised about expanding the inheritence tree twice.
>
> To address that concern, I'm thinking to redesign the patch so that it
> wouldn't expand the tree at planning time anymore. I don't have any
> clear solution for that yet, but what I have in mind now is to add new
> FDW APIs to the executor, instead, so that the FDW could 1) create stuff
> such as a query for remote INSERT as PlanForeignModify and 2)
> initialize/end the remote INSERT operation as BeginForeignModify and
> EndForeignModify, somewhere in the executor.
New FDW APIs I would like to propose for that are:
void
BeginForeignRouting(ModifyTableState *mtstate,
ResultRelInfo *resultRelInfo,
int partition_index);
Prepare for a tuple-routing operation on a foreign table. This is
called from ExecSetupPartitionTupleRouting and ExecInitPartitionInfo.
TupleTableSlot *
ExecForeignRouting(EState *estate,
ResultRelInfo *resultRelInfo,
TupleTableSlot *slot);
Route one tuple to the foreign table. This is called from ExecInsert.
void
EndForeignRouting(EState *estate,
ResultRelInfo *resultRelInfo);
End the operation and release resources. This is called from
ExecCleanupTupleRouting.
Attached are WIP patches for that:
Patch postgres-fdw-refactoring-WIP.patch: refactoring patch for
postgres_fdw.c to reduce duplicate code.
Patch foreign-routing-fdwapi-WIP.patch: main patch to add new FDW APIs,
which is created on top of patch postgres-fdw-refactoring-WIP.patch and
the lazy-initialization-of-partition-info patch [1].
By this change we don't need to expand the inheritance tree at planning
time, so no need to worry about the performance concern. Maybe I'm
missing something, though. Early feedback would be greatly appreciated.
Best regards,
Etsuro Fujita
[1] https://www.postgresql.org/message-id/5A8BFB31.6030707@lab.ntt.co.jp