Re: [HACKERS] UPDATE of partition key
От | Amit Khandekar |
---|---|
Тема | Re: [HACKERS] UPDATE of partition key |
Дата | |
Msg-id | CAJ3gD9ffLqsYvLX+sVbNKSkML+V3CCKq0k_kp9qo=jpSfBQXYg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] UPDATE of partition key (Amit Khandekar <amitdkhan.pg@gmail.com>) |
Ответы |
Re: [HACKERS] UPDATE of partition key
|
Список | pgsql-hackers |
While rebasing my patch for the below recent commit, I realized that a similar issue exists for the uptate-tuple-routing patch as well : commit 78a030a441966d91bc7e932ef84da39c3ea7d970 Author: Tom Lane <tgl@sss.pgh.pa.us> Date: Mon Jun 12 23:29:44 2017 -0400 Fix confusion about number of subplans in partitioned INSERT setup. The above issue was about incorrectly using 'i' in mtstate->mt_plans[i] during handling WITH CHECK OPTIONS in ExecInitModifyTable(), where 'i' was actually meant to refer to the positions in mtstate->mt_num_partitions. Actually for INSERT, there is only a single plan element in mtstate->mt_plans[] array. Similarly, for update-tuple routing, we cannot use mtstate->mt_plans[i], because 'i' refers to position in mtstate->mt_partitions[] , whereas mtstate->mt_plans is not at all in order of mtstate->mt_partitions; in fact mt_plans has only the plans that are to be scanned on pruned partitions; so it can well be a small subset of total partitions. I am working on an updated patch to fix the above.
В списке pgsql-hackers по дате отправления: