Re: UPDATE of partition key
Amit Khandekar <amitdkhan.pg@gmail.com>
On 31 August 2017 at 14:15, Amit Khandekar <amitdkhan.pg@gmail.com> wrote: > Thanks Dilip. I am working on rebasing the patch. Particularly, the > partition walker in my patch depended on the fact that all the tables > get opened (and then closed) while creating the tuple routing info. > But in HEAD, now only the partitioned tables get opened. So need some > changes in my patch. > > The partition walker related changes are going to be inapplicable once > the other thread [1] commits the changes for expansion of inheritence > in bound-order, but till then I would have to rebase the partition > walker changes over HEAD. > > [1] https://www.postgresql.org/message-id/0118a1f2-84bb-19a7-b906-dec040a206f2%40lab.ntt.co.jp > After recent commit 30833ba154, now the partitions are expanded in depth-first order. It didn't seem worthwhile rebasing my partition walker changes onto the latest code. So in the attached patch, I have removed all the partition walker changes. But RelationGetPartitionDispatchInfo() traverses in breadth-first order, which is different than the update result rels order (because inheritance expansion order is depth-first). So, in order to make the tuple-routing-related leaf partitions in the same order as that of the update result rels, we would have to make changes in RelationGetPartitionDispatchInfo(), which I am not sure whether it is going to be done as part of the thread "expanding inheritance in partition bound order" [1]. For now, in the attached patch, I have reverted back to the hash table method to find the leaf partitions in the update result rels. [1] https://www.postgresql.org/message-id/CAJ3gD9eyudCNU6V-veMme%2BeyzfX_ey%2BgEzULMzOw26c3f9rzdg%40mail.gmail.com Thanks -Amit Khandekar
Commits
-
Avoid referencing off the end of subplan_partition_offsets.
- 945f71db8452 11.0 landed
-
Allow UPDATE to move rows between partitions.
- 2f178441044b 11.0 landed
-
Remove useless lookup of root partitioned rel in ExecInitModifyTable().
- dca48d145e0e 11.0 cited
-
Factor error generation out of ExecPartitionCheck.
- 19c47e7c8202 11.0 landed
-
Minor preparatory refactoring for UPDATE row movement.
- ef6087ee5fa8 11.0 landed
-
Simplify and encapsulate tuple routing support code.
- cc6337d2fed5 11.0 landed
-
Avoid coercing a whole-row variable that is already coerced.
- 1c497fa72df7 11.0 landed
-
Use ResultRelInfo ** rather than ResultRelInfo * for tuple routing.
- 60f7c0abef03 11.0 landed
-
Make RelationGetPartitionDispatchInfo expand depth-first.
- 77b6b5e9ceca 11.0 cited
-
Expand partitioned tables in PartDesc order.
- 30833ba154e0 11.0 cited
-
Use a real RT index when setting up partition tuple routing.
- f81a91db4d1c 10.0 cited
-
Fix transition tables for partition/inheritance.
- 501ed02cf6f4 10.0 cited
-
Fix confusion about number of subplans in partitioned INSERT setup.
- 78a030a44196 10.0 cited
-
Prevent BEFORE triggers from violating partitioning constraints.
- 15ce775faa42 10.0 cited
-
Fire per-statement triggers on partitioned tables.
- e180c8aa8caf 10.0 cited
-
Fix reporting of violations in ExecConstraints, again.
- c0a8ae7be392 10.0 cited
-
Don't scan partitioned tables.
- d3cc37f1d801 10.0 cited
-
Allow FDWs to push down quals without breaking EvalPlanQual rechecks.
- 5fc4c26db512 9.6.0 cited