diff options
| -rw-r--r-- | src/backend/utils/sort/tuplesort.c | 16 |
1 files 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); |