Horton

Re: Oddity in tuple routing for foreign partitions

Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>

View thread View on postgr.es
From: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2018-04-26T03:41:13Z
Lists: pgsql-hackers 
(2018/04/25 17:51), Etsuro Fujita wrote:
> (2018/04/25 4:49), Robert Haas wrote:
>> I didn't really get beyond the refactoring stage with this today.
>> This version still seems to work, but I don't really understand the
>> logic in postgresBeginForeignInsert which decides whether to use the
>> RTE from the range table or create our own. We seem to need to do one
>> sometimes and the other sometimes, but I don't know why that is,
>> really. Nor do I understand why we need the other changes in the
>> patch. There's probably a good reason, but I haven't figured it out
>> yet.
>
> To reduce the cost of creating RTEs, the original patch uses the RTE in
> the range table if the partition is an UPDATE subplan partition.

One thing to add: in addition to that case, the original patch uses the 
RTE in the range table if the foreign table is the target specified in a 
COPY command.

Best regards,
Etsuro Fujita

Commits

  1. Remove now-unnecessary cast.

  2. Fix interaction of foreign tuple routing with remote triggers.