bizgres - bizgres: Tom Lane, Simon Riggs 1. - Mailing list pgsql-committers

From aparashar@pgfoundry.org (User Aparashar)
Subject bizgres - bizgres: Tom Lane, Simon Riggs 1.
Date
Msg-id 20060322073706.ED867103384D@pgfoundry.org
Whole thread Raw
List pgsql-committers
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)

pgsql-committers by date:

Previous
From: aparashar@pgfoundry.org (User Aparashar)
Date:
Subject: bizgres - bizgres: Teach nodeSort and nodeMaterial to optimize out
Next
From: jwp@pgfoundry.org (James William Pye)
Date:
Subject: python - fe: Asyncs can occur while waiting for Ready.