| From: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Oddity in tuple routing for foreign partitions |
| Date: | 2018-04-26 03:41:13 |
| Message-ID: | 5AE14A59.80304@lab.ntt.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Etsuro Fujita | 2018-04-26 03:43:17 | Re: Oddity in tuple routing for foreign partitions |
| Previous Message | Haribabu Kommi | 2018-04-26 03:34:44 | jitflags in _outPlannedStmt and _readPlannedStmt treated as bool type |