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  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Список 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 по дате отправления:

Предыдущее
От: Ashutosh Bapat
Дата:
Сообщение: Re: [HACKERS] expanding inheritance in partition bound order
Следующее
От: Etsuro Fujita
Дата:
Сообщение: Re: [HACKERS] Tuple-routing for certain partitioned tables notworking as expected