Re: [HACKERS] Tuple-routing for certain partitioned tables notworking as expected

Поиск
Список
Период
Сортировка
От Etsuro Fujita
Тема Re: [HACKERS] Tuple-routing for certain partitioned tables notworking as expected
Дата
Msg-id d5797ceb-627b-ee68-06c2-79247b89e573@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: [HACKERS] Tuple-routing for certain partitioned tables notworking as expected  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Ответы Re: [HACKERS] Tuple-routing for certain partitioned tables notworking as expected  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Список pgsql-hackers
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.

Best regards,
Etsuro Fujita

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: [HACKERS] [TRAP: FailedAssertion] causing server to crash
Следующее
От: Rajkumar Raghuwanshi
Дата:
Сообщение: Re: [HACKERS] UPDATE of partition key