NotificationsYou must be signed in to change notification settings
Fork6
Star31

Commit95b5235

committed

Remove obsolete comment.

Commit8b304b8 removed replacementselection, but left behind this comment text. The optimization towhich the comment refers is not relevant without replacementselection, because if we had so few tuples as to require only onetape, we would have just completed the sort in memory.Peter GeogheganDiscussion:http://postgr.es/m/CAH2-WznqupLA8CMjp+vqzoe0yXu0DYYbQSNZxmgN76tLnAOZ_w@mail.gmail.com

1 parentd329dc2 commit95b5235Copy full SHA for 95b5235

File tree

1 file changed

-5

lines changed

src/backend/utils/sort
- tuplesort.c

1 file changed

-5

lines changed

`‎src/backend/utils/sort/tuplesort.c`

Lines changed: 0 additions & 5 deletions

Original file line number	Diff line number	Diff line change
`@@ -2459,11 +2459,6 @@ mergeruns(Tuplesortstate *state)`
`2459`	`2459`	`* Use all the remaining memory we have available for read buffers among`
`2460`	`2460`	`* the input tapes.`
`2461`	`2461`	`*`
`2462`		`- * We do this only after checking for the case that we produced only one`
`2463`		`- * initial run, because there is no need to use a large read buffer when`
`2464`		`- * we're reading from a single tape. With one tape, the I/O pattern will`
`2465`		`- * be the same regardless of the buffer size.`
`2466`		`- *`
`2467`	`2462`	`* We don't try to "rebalance" the memory among tapes, when we start a new`
`2468`	`2463`	`* merge phase, even if some tapes are inactive in the new phase. That`
`2469`	`2464`	`* would be hard, because logtape.c doesn't know where one run ends and`

0 commit comments

Comments

(0)

Movatterモバイル変換

Navigation Menu

Search code, repositories, users, issues, pull requests...

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Commit95b5235

File tree

1 file changed

1 file changed

`‎src/backend/utils/sort/tuplesort.c`

0 commit comments