rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update comment. 

mergepreread()/mergeprereadone() don't exist anymore, the function that
does roughly the same is now called mergereadnext().
This commit is contained in:
Heikki Linnakangas 2016-10-04 09:46:43 +03:00
parent 61633f7904
commit c86c2d9d57
1 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
src/backend/utils/sort/tuplesort.c
View File

@ -3083,14 +3083,14 @@ dumpbatch(Tuplesortstate *state, bool alltuples)
* a call with no subsequent run actually written to destTape), we prefer * a call with no subsequent run actually written to destTape), we prefer
* to write out a 0 tuple run. * to write out a 0 tuple run.
* *
* mergepreread()/mergeprereadone() are prepared for 0 tuple runs, and * mergereadnext() is prepared for 0 tuple runs, and will reliably mark
* will reliably mark the tape inactive for the merge when called from * the tape inactive for the merge when called from beginmerge(). This
* beginmerge(). This case is therefore similar to the case where * case is therefore similar to the case where mergeonerun() finds a dummy
* mergeonerun() finds a dummy run for the tape, and so doesn't need to * run for the tape, and so doesn't need to merge a run from the tape (or
* merge a run from the tape (or conceptually "merges" the dummy run, if * conceptually "merges" the dummy run, if you prefer). According to
* you prefer). According to Knuth, Algorithm D "isn't strictly optimal" * Knuth, Algorithm D "isn't strictly optimal" in its method of
* in its method of distribution and dummy run assignment; this edge case * distribution and dummy run assignment; this edge case seems very
* seems very unlikely to make that appreciably worse. * unlikely to make that appreciably worse.
*/ */
Assert(state->status == TSS_BUILDRUNS); Assert(state->status == TSS_BUILDRUNS);