From c86c2d9d57c1e6c5fec860873734cccaf31df5b0 Mon Sep 17 00:00:00 2001 From: Heikki Linnakangas <heikki.linnakangas@iki.fi> Date: Tue, 4 Oct 2016 09:46:43 +0300 Subject: [PATCH] Update comment. mergepreread()/mergeprereadone() don't exist anymore, the function that does roughly the same is now called mergereadnext(). --- src/backend/utils/sort/tuplesort.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/src/backend/utils/sort/tuplesort.c b/src/backend/utils/sort/tuplesort.c index 20cfb0b139c..5ff81ed95aa 100644 --- a/src/backend/utils/sort/tuplesort.c +++ b/src/backend/utils/sort/tuplesort.c @@ -3083,14 +3083,14 @@ dumpbatch(Tuplesortstate *state, bool alltuples) * a call with no subsequent run actually written to destTape), we prefer * to write out a 0 tuple run. * - * mergepreread()/mergeprereadone() are prepared for 0 tuple runs, and - * will reliably mark the tape inactive for the merge when called from - * beginmerge(). This case is therefore similar to the case where - * mergeonerun() finds a dummy run for the tape, and so doesn't need to - * merge a run from the tape (or conceptually "merges" the dummy run, if - * you prefer). According to Knuth, Algorithm D "isn't strictly optimal" - * in its method of distribution and dummy run assignment; this edge case - * seems very unlikely to make that appreciably worse. + * mergereadnext() is prepared for 0 tuple runs, and will reliably mark + * the tape inactive for the merge when called from beginmerge(). This + * case is therefore similar to the case where mergeonerun() finds a dummy + * run for the tape, and so doesn't need to merge a run from the tape (or + * conceptually "merges" the dummy run, if you prefer). According to + * Knuth, Algorithm D "isn't strictly optimal" in its method of + * distribution and dummy run assignment; this edge case seems very + * unlikely to make that appreciably worse. */ Assert(state->status == TSS_BUILDRUNS); -- GitLab