From a82178020de2c4b3576d0a079e11a431e382e4de Mon Sep 17 00:00:00 2001 From: Robert Haas Date: Tue, 14 Mar 2017 07:52:11 -0400 Subject: [PATCH] Update overlooked comment for Gather Merge. Commit 355d3993c53ed62c5b53d020648e4fbcfbf5f155 probably should have done this, but nobody noticed that it was needed. --- src/backend/optimizer/plan/createplan.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/backend/optimizer/plan/createplan.c b/src/backend/optimizer/plan/createplan.c index 64f0ee55ec..4629ca27ee 100644 --- a/src/backend/optimizer/plan/createplan.c +++ b/src/backend/optimizer/plan/createplan.c @@ -5390,9 +5390,9 @@ make_sort(Plan *lefttree, int numCols, * prepare_sort_from_pathkeys * Prepare to sort according to given pathkeys * - * This is used to set up for both Sort and MergeAppend nodes. It calculates - * the executor's representation of the sort key information, and adjusts the - * plan targetlist if needed to add resjunk sort columns. + * This is used to set up for Sort, MergeAppend, and Gather Merge nodes. It + * calculates the executor's representation of the sort key information, and + * adjusts the plan targetlist if needed to add resjunk sort columns. * * Input parameters: * 'lefttree' is the plan node which yields input tuples @@ -5416,7 +5416,7 @@ make_sort(Plan *lefttree, int numCols, * * If the pathkeys include expressions that aren't simple Vars, we will * usually need to add resjunk items to the input plan's targetlist to - * compute these expressions, since the Sort/MergeAppend node itself won't + * compute these expressions, since a Sort or MergeAppend node itself won't * do any such calculations. If the input plan type isn't one that can do * projections, this means adding a Result node just to do the projection. * However, the caller can pass adjust_tlist_in_place = TRUE to force the -- 2.40.0