This is an automated email from the ASF dual-hosted git repository. yjhjstz pushed a commit to branch main in repository https://gitbox.apache.org/repos/asf/cloudberry.git
commit e3953aa9d6f334a12b96294b0de51d522c5da667 Author: xuejing zhao <[email protected]> AuthorDate: Wed Oct 11 10:28:36 2023 +0800 resolve GPDB_96_MERGE_FIXME for SplitUpdate (#16560) The comments for create_split_update_path: ``` GPDB_96_MERGE_FIXME: the below comment is obsolete. Nowadays, SplitUpdate computes the new row's hash, and the corresponding. target segment. The old segment comes from the gp_segment_id junk column. But ORCA still does it the old way! Third, to support deletion, and hash delete operation to correct segment, we need to get attributes of OLD tuple. The old attributes must therefore be present in the subplan's target list. That is handled earlier in the planner, in expand_targetlist(). ``` For planner we use Explicit Redistribute Motion instead of Redistribute Motion above the split node, So old attributes is useless to compute target segment id for Redistribute Motion. remove above comments. --- src/backend/cdb/cdbpath.c | 15 +++------------ 1 file changed, 3 insertions(+), 12 deletions(-) diff --git a/src/backend/cdb/cdbpath.c b/src/backend/cdb/cdbpath.c index 2d90f63ad9..fcc390ab60 100644 --- a/src/backend/cdb/cdbpath.c +++ b/src/backend/cdb/cdbpath.c @@ -2703,28 +2703,19 @@ create_motion_path_for_upddel(PlannerInfo *root, Index rti, GpPolicy *policy, * consist of a delete and insert. So, if the result relation has update * triggers, we should reject and error out because it's not functional. * - * GPDB_96_MERGE_FIXME: the below comment is obsolete. Nowadays, SplitUpdate - * computes the new row's hash, and the corresponding. target segment. The - * old segment comes from the gp_segment_id junk column. But ORCA still - * does it the old way! - * - * Third, to support deletion, and hash delete operation to correct segment, - * we need to get attributes of OLD tuple. The old attributes must therefore - * be present in the subplan's target list. That is handled earlier in the - * planner, in expand_targetlist(). * * For example, a typical plan would be as following for statement: * update foo set id = l.v + 1 from dep l where foo.v = l.id: * - * |-- join ( targetlist: [ l.v + 1, foo.v, foo.id, foo.ctid, foo.gp_segment_id ] ) + * |-- join ( targetlist: [ l.v + 1, foo.v, foo.ctid, foo.gp_segment_id ] ) * | * |-- motion ( targetlist: [l.id, l.v] ) * | | * | |-- seqscan on dep .... * | - * |-- hash (targetlist [ v, foo.ctid, foo.gp_segment_id ] ) + * |-- hash (targetlist [ foo.v, foo.ctid, foo.gp_segment_id ] ) * | - * |-- seqscan on foo (targetlist: [ v, foo.id, foo.ctid, foo.gp_segment_id ] ) + * |-- seqscan on foo (targetlist: [ foo.v, foo.ctid, foo.gp_segment_id ] ) * * From the plan above, the target foo.id is assigned as l.v + 1, and expand_targetlist() * ensured that the old value of id, is also available, even though it would not otherwise --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
