| From: | Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: UPDATE of partition key |
| Date: | 2017-06-13 10:10:33 |
| Message-ID: | CAJ3gD9ffLqsYvLX+sVbNKSkML+V3CCKq0k_kp9qo=jpSfBQXYg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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(at)sss(dot)pgh(dot)pa(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2017-06-13 11:50:55 | Re: Broken hint bits (freeze) |
| Previous Message | Amit Langote | 2017-06-13 09:22:54 | Re: fix possible optimizations in ATExecAttachPartition() |