Update comment.

mergepreread()/mergeprereadone() don't exist anymore, the function that
does roughly the same is now called mergereadnext().

diff --git a/src/backend/utils/sort/tuplesort.c b/src/backend/utils/sort/tuplesort.c
index 20cfb0b139cca44551fd46872ce45e7701b203ad..5ff81ed95aa415cf1154fe56685a3454b60a53dc 100644 (file)
--- 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);