Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Commit fc19c18

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 parent 00c6d80 commit fc19c18

File tree

1 file changed

+15
-2
lines changed

1 file changed

+15
-2
lines changed

src/backend/utils/sort/tuplesort.c

+15-2
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
#define MINORDER 6 /* minimum merge order */
251+
#define MAXORDER 500 /* maximum merge order */
250252
#define TAPE_BUFFER_OVERHEAD (BLCKSZ * 3)
251253
#define MERGE_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
return mOrder;
23202333
}

0 commit comments

Comments
 (0)