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

Commitc27033f

Browse files
committed
Update tuplesort.c comments for memory mangement improvements.
I'm committing these changes separately so that it's clear what isPeter's original work versus what I changed. This is a followup tocommit0011c00, and these changesare all by me.
1 parent0011c00 commitc27033f

File tree

1 file changed

+20
-6
lines changed

1 file changed

+20
-6
lines changed

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

Lines changed: 20 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -227,7 +227,7 @@ struct Tuplesortstate
227227
intmaxTapes;/* number of tapes (Knuth's T) */
228228
inttapeRange;/* maxTapes-1 (Knuth's P) */
229229
MemoryContextsortcontext;/* memory context holding most sort data */
230-
MemoryContexttuplecontext;/*memorycontextholding tuple data */
230+
MemoryContexttuplecontext;/*sub-contextof sortcontext for tuple data */
231231
LogicalTapeSet*tapeset;/* logtape.c object for tapes in a temp file */
232232

233233
/*
@@ -2536,8 +2536,11 @@ mergeonerun(Tuplesortstate *state)
25362536
}
25372537

25382538
/*
2539-
* Reset tuple memory, now that no caller tuples are needed in memory.
2540-
* This prevents fragmentation.
2539+
* Reset tuple memory. We've freed all of the tuples that we previously
2540+
* allocated, but AllocSetFree will have put those chunks of memory on
2541+
* particular free lists, bucketed by size class. Thus, although all of
2542+
* that memory is free, it is effectively fragmented. Resetting the
2543+
* context gets us out from under that problem.
25412544
*/
25422545
MemoryContextReset(state->tuplecontext);
25432546

@@ -2710,10 +2713,21 @@ beginmerge(Tuplesortstate *state, bool finalMergeBatch)
27102713
* allocated slots. However, though slots and tuple memory is in balance
27112714
* following the last grow_memtuples() call, that's predicated on the observed
27122715
* average tuple size for the "final" grow_memtuples() call, which includes
2713-
* palloc overhead.
2716+
* palloc overhead. During the final merge pass, where we will arrange to
2717+
* squeeze out the palloc overhead, we might need more slots in the memtuples
2718+
* array.
27142719
*
2715-
* This will perform an actual final grow_memtuples() call without any palloc()
2716-
* overhead, rebalancing the use of memory between slots and tuples.
2720+
* To make that happen, arrange for the amount of remaining memory to be
2721+
* exactly equal to the palloc overhead multiplied by the current size of
2722+
* the memtuples array, force the grow_memtuples flag back to true (it's
2723+
* probably but not necessarily false on entry to this routine), and then
2724+
* call grow_memtuples. This simulates loading enough tuples to fill the
2725+
* whole memtuples array and then having some space left over because of the
2726+
* elided palloc overhead. We expect that grow_memtuples() will conclude that
2727+
* it can't double the size of the memtuples array but that it can increase
2728+
* it by some percentage; but if it does decide to double it, that just means
2729+
* that we've never managed to use many slots in the memtuples array, in which
2730+
* case doubling it shouldn't hurt anything anyway.
27172731
*/
27182732
staticvoid
27192733
batchmemtuples(Tuplesortstate*state)

0 commit comments

Comments
 (0)

[8]ページ先頭

©2009-2025 Movatter.jp