Tom Lane wrote: > Stefan Kaltenbrunner <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings