forked from apache/cloudberry
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Expand partition table leaves in parallel.
This commit brings back the feature that we can parallelly redistribute data of the same partition table's leaf partitions during gpexpand's second stage. It is implemented via several clear small commits (finally squash and commit as this one big commit) so for details please refer to the Github PR page: This feature is important not only because we can speed up due to more concurrency, but also because it can save a lot of disk. Expanding a table to new cluster size is implemented by CTAS in Greenplum, CTAS can only remove old data at the end of the transaction. One leaf per transaction can make sure we remove useless data quickly. The most important theory here is Parent-Child Distribution Policy Invariant, for details please refer to Heikki's comments in https://groups.google.com/a/greenplum.org/g/gpdb-dev/c/rSacd_vI-fM/m/pkAW-Z-lCgAJ Following list what this commit has done: 1. Introduce a new Statement `ALTER TABLE EXPAND PARTITION PREPARE`. This statement can only be used for partition table's root (before expanding to new cluster size). For hash distributed partition table, it will make the root (of middle) hash distributed to the full cluster, and all leafs to full randomly distributed to the full cluster in single transaction. Heaviest locks will be held in this step and because no data is touching this transaction will be fast. 2. Modify the implementation of `Alter Table Set Distributed by` to allow operate on leafs. The constrain now is to obey Parent-Child Distribution Policy Invariant, so you can directly operate on leafs if the target policy of the leaf is the same as the root. Then later we can use this to concurrently expand leafs. 3. Change gpexpand script to fully work. First, it will invoke `prepare expand` to change policy and then during state_details table built (1st stage of gpexpand), we will not put root in the queue that need to expand. We put leafs instead. Later for leafs expansion in 2nd stage, we use `alter table set distributed by` for them because their numsegments are already the full cluster size. 4. Finish writable external leaf partitions during prepare-stage. For Foreign|External tables, only writable external table has gp_policy entry and to expand them we just need to change the catalog without any data movement. So any foreign|external leaf partitions, if writable, expand during prepare-stage, otherwise just ignore. Authored-by: Xuejing Zhao <zxuejing@vmware.com> Authored-by: Jian Guo <xihuke@gmail.com> Authored-by: Xuebin Su <sxuebin@vmware.com> Authored-by: Yini Li <yinil@vmware.com> Authored-by: Zhenghua Lyu <kainwen@gmail.com> Reviewed-by: Alexandra Wang <walexandra@vmware.com> Inspired-by: uglthinx
- Loading branch information
Showing
14 changed files
with
2,021 additions
and
75 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.