Re: problem with large maintenance_work_mem settings and

Tom Lane wrote:
> Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> writes:
>
>>samples % symbol name
>>103520432 47.9018 inlineApplySortFunction
>>33382738 15.4471 comparetup_index
>>25296438 11.7054 tuplesort_heap_siftup
>>10089122 4.6685 btint4cmp
>>8395676 3.8849 LogicalTapeRead
>>2873556 1.3297 tuplesort_heap_insert
>>2796545 1.2940 tuplesort_gettuple_common
>>2752345 1.2736 AllocSetFree
>>2233889 1.0337 IndexBuildHeapScan
>
>
> Interesting. What's the platform, and what compiler exactly? For me,
> gcc seems to inline inlineApplySortFunction successfully, but your
> compiler evidently is not doing that.

Debian Sarge/AMD64 with gcc version 3.3.5 (Debian 1:3.3.5-13) running on
a Dual AMD Opteron 280 (so 4 cores @2,4GHz) with 16GB of RAM and a very
recent Kernel.
Debian has gcc 3.4 as an optional package in Sarge too so I certainly
can try that one.

[...]

> Your machine seems not to be subject to nearly the same amount of memory
> delay. Which is interesting because most of the argument for changing
> sort algorithms seems to hinge on the assumption that main-memory delay
> is the main thing we need to worry about. That looks to be valid on the
> Xeon I'm testing but not on your machine ...

hmm very interesting, Opterons are known for there very high memory
bandwidth and some (rather limited) testing using various benchmarktools
against a 3,2Ghz DP Xeon with 2MB L2 cache shows that the Opteron box
really has a significant advantage here ...

Stefan