Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

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

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Commitfc19c18

Browse files
committed
Limit the number of number of tapes used for a sort to 501.
Gigantic numbers of tapes don't work out well.Original patch by Peter Geoghegan; comments entirely rewritten by me.
1 parent00c6d80 commitfc19c18

File tree

1 file changed

+15
-2
lines changed

1 file changed

+15
-2
lines changed

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

Lines changed: 15 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -108,7 +108,8 @@
108108
* code we determine the number of tapes M on the basis of workMem: we want
109109
* workMem/M to be large enough that we read a fair amount of data each time
110110
* we preread from a tape, so as to maintain the locality of access described
111-
* above. Nonetheless, with large workMem we can have many tapes.
111+
* above. Nonetheless, with large workMem we can have many tapes (but not
112+
* too many -- see the comments in tuplesort_merge_order).
112113
*
113114
*
114115
* Portions Copyright (c) 1996-2016, PostgreSQL Global Development Group
@@ -247,6 +248,7 @@ typedef enum
247248
* tape during a preread cycle (see discussion at top of file).
248249
*/
249250
#defineMINORDER6/* minimum merge order */
251+
#defineMAXORDER500/* maximum merge order */
250252
#defineTAPE_BUFFER_OVERHEAD(BLCKSZ * 3)
251253
#defineMERGE_BUFFER_SIZE(BLCKSZ * 32)
252254

@@ -2313,8 +2315,19 @@ tuplesort_merge_order(int64 allowedMem)
23132315
mOrder= (allowedMem-TAPE_BUFFER_OVERHEAD) /
23142316
(MERGE_BUFFER_SIZE+TAPE_BUFFER_OVERHEAD);
23152317

2316-
/* Even in minimum memory, use at least a MINORDER merge */
2318+
/*
2319+
* Even in minimum memory, use at least a MINORDER merge. On the other
2320+
* hand, even when we have lots of memory, do not use more than a MAXORDER
2321+
* merge. Tapes are pretty cheap, but they're not entirely free. Each
2322+
* additional tape reduces the amount of memory available to build runs,
2323+
* which in turn can cause the same sort to need more runs, which makes
2324+
* merging slower even if it can still be done in a single pass. Also,
2325+
* high order merges are quite slow due to CPU cache effects; it can be
2326+
* faster to pay the I/O cost of a polyphase merge than to perform a single
2327+
* merge pass across many hundreds of tapes.
2328+
*/
23172329
mOrder=Max(mOrder,MINORDER);
2330+
mOrder=Min(mOrder,MAXORDER);
23182331

23192332
returnmOrder;
23202333
}

0 commit comments

Comments
 (0)

[8]ページ先頭

©2009-2025 Movatter.jp