Log Message:
-----------
Tom Lane, Simon Riggs
1. Prevent sorting from requesting a SortTuple array that exceeds MaxAllocSize;
we'll go over to disk-based sort if we reach that limit.
This fixes Stefan Kaltenbrunner's observation that sorting can suffer an
'invalid memory alloc request size' failure when sort_mem is set large
enough. It's unfortunately not so easy to fix in 8.1 ...
2. Repair old performance bug in tuplesort.c/logtape.c. In the case where
we are doing the final merge pass on-the-fly, and not writing the data
back onto a 'tape', the number of free blocks in the tape set will become
large, leading to a lot of time wasted in ltsReleaseBlock(). There is
really no need to track the free blocks anymore in this state, so add a
simple shutoff switch. Per report from Stefan Kaltenbrunner.
3. Tweak trace_sort code to show the merge order (number of active input
tapes) for each merge step. This will give us some idea of how effective
the merge distribution algorithm is.
4. 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.
Modified Files:
--------------
bizgres/postgresql/src/include/utils:
tuplesort.h (r1.2 -> r1.3)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/bizgres/bizgres/postgresql/src/include/utils/tuplesort.h.diff?r1=1.2&r2=1.3)
bizgres/postgresql/src/backend/utils/sort:
tuplesort.c (r1.2 -> r1.3)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/bizgres/bizgres/postgresql/src/backend/utils/sort/tuplesort.c.diff?r1=1.2&r2=1.3)
logtape.c (r1.2 -> r1.3)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/bizgres/bizgres/postgresql/src/backend/utils/sort/logtape.c.diff?r1=1.2&r2=1.3)