]> granicus.if.org Git - postgresql/commit
Recent changes in memory management in tuplesort.c had a problem: the
authorTom Lane <tgl@sss.pgh.pa.us>
Fri, 10 Mar 2006 23:19:00 +0000 (23:19 +0000)
committerTom Lane <tgl@sss.pgh.pa.us>
Fri, 10 Mar 2006 23:19:00 +0000 (23:19 +0000)
commitc65ab0bfa97b71bceae6402498910f4074996279
treed19ffaf0db36b98ad12fee54d6712181f56b8c8e
parent9f6192490eec2a27b84d68d16f7b268a5ddbfd55
Recent changes in memory management in tuplesort.c had a problem: the
case where we run low on array slots before we run low on memory is much
more probable than I had thought, and so it's important to treat each
tape fairly in that case.  To fix this, track per-tape slot allocations
just like we track per-tape space allocation.  Also, in the FINALMERGE
code path avoid scanning all the input tapes when we really only need to
read from one.  This should fix poor behavior with very large work_mem
as exhibited by Stefan Kaltenbrunner.
I didn't do anything about putting an upper bound on the number of tapes,
but maybe we should still consider that.
src/backend/utils/sort/tuplesort.c