Re: [HACKERS] Tuple-routing for certain partitioned tables notworking as expected
От | Amit Langote |
---|---|
Тема | Re: [HACKERS] Tuple-routing for certain partitioned tables notworking as expected |
Дата | |
Msg-id | 5cd6c910-bd7b-32af-5d47-54a441624757@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] Tuple-routing for certain partitioned tables notworking as expected (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>) |
Ответы |
Re: [HACKERS] Tuple-routing for certain partitioned tables notworking as expected
|
Список | pgsql-hackers |
On 2017/08/07 15:22, Etsuro Fujita wrote: > On 2017/08/07 13:11, Amit Langote wrote:> The patch looks good too. > Although, looking at the following hunk: >> >> + Assert(partrel->rd_rel->relkind == RELKIND_RELATION || >> + partrel->rd_rel->relkind == RELKIND_FOREIGN_TABLE); >> + >> /* >> * Verify result relation is a valid target for the current >> operation. >> */ >> ! if (partrel->rd_rel->relkind == RELKIND_RELATION) >> ! CheckValidResultRel(partrel, CMD_INSERT); >> >> makes me now wonder if we need the CheckValidResultRel check at all. The >> only check currently in place for RELKIND_RELATION is >> CheckCmdReplicaIdentity(), which is a noop (returns true) for inserts >> anyway. > > Good point! I left the verification for a plain table because that is > harmless but as you mentioned, that is nothing but an overhead. So, here > is a new version which removes the verification at all from > ExecSetupPartitionTupleRouting. The updated patch looks good to me, thanks. Regards, Amit
В списке pgsql-hackers по дате отправления: