aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRobert Haas <rhaas@postgresql.org>2017-12-12 19:33:50 -0500
committerRobert Haas <rhaas@postgresql.org>2017-12-12 19:33:50 -0500
commit95b52351fe966c93791462274dfa7af7e50d2da1 (patch)
treee70c7a2cdc17c8c9bc5119c9f17a3231fe548a7b
parentd329dc2ea4bfac84ec60ba14b96561a7508bb37b (diff)
downloadpostgresql-95b52351fe966c93791462274dfa7af7e50d2da1.tar.gz
postgresql-95b52351fe966c93791462274dfa7af7e50d2da1.zip
Remove obsolete comment.
Commit 8b304b8b72b0a60f1968d39f01cf817c8df863ec removed replacement selection, but left behind this comment text. The optimization to which the comment refers is not relevant without replacement selection, because if we had so few tuples as to require only one tape, we would have just completed the sort in memory. Peter Geoghegan Discussion: http://postgr.es/m/CAH2-WznqupLA8CMjp+vqzoe0yXu0DYYbQSNZxmgN76tLnAOZ_w@mail.gmail.com
-rw-r--r--src/backend/utils/sort/tuplesort.c5
1 files changed, 0 insertions, 5 deletions
diff --git a/src/backend/utils/sort/tuplesort.c b/src/backend/utils/sort/tuplesort.c
index 3c23ac75a09..35eebad8e4c 100644
--- a/src/backend/utils/sort/tuplesort.c
+++ b/src/backend/utils/sort/tuplesort.c
@@ -2459,11 +2459,6 @@ mergeruns(Tuplesortstate *state)
* Use all the remaining memory we have available for read buffers among
* the input tapes.
*
- * We do this only after checking for the case that we produced only one
- * initial run, because there is no need to use a large read buffer when
- * we're reading from a single tape. With one tape, the I/O pattern will
- * be the same regardless of the buffer size.
- *
* We don't try to "rebalance" the memory among tapes, when we start a new
* merge phase, even if some tapes are inactive in the new phase. That
* would be hard, because logtape.c doesn't know where one run ends and