On Tue, 2005-10-04 at 00:21 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
AFAICS the following opportunities exist, without changing any of the
theoretical algorithms or the flexibility of definable datatypes:
1. tuplesort_heap_siftup and tuplesort_heap_insert make no
On Tue, Oct 04, 2005 at 12:37:51AM +0100, Simon Riggs wrote:
On Mon, 2005-10-03 at 23:25 +0200, Martijn van Oosterhout wrote:
Please note: if inlineApplySortFunction() is actually inlined (it isn't
by default)
Can you explain your last post some more. Thats not what I get.
The inline
On Tue, Oct 04, 2005 at 11:55:58AM +0200, Martijn van Oosterhout wrote:
It goes in to say that the limit is 1 for gcc 2.95, but if you
examine the manual for gcc 3.3 it has the limit at 600. So it's
entirely possible that at the time the person wrote that code, it *was*
being inlined, but
On Tue, 2005-10-04 at 12:37 +0200, Martijn van Oosterhout wrote:
Since we're pretty much relying on gcc to inline for performance, I
still think we should add -Winline by default so we can tell when it's
not doing what we want.
Very much agree to this. Can we put that in the build for 8.1
Based upon profiling of the initial stage of external sorting, it seems
that this stage is overall CPU bound, with hotspots in comparetup_*
accounting for around 50% of CPU time; lets just call that too much,
since your exact experience may vary.
Previously, I'd looked through all of the code
On Mon, Oct 03, 2005 at 09:35:30PM +0100, Simon Riggs wrote:
Based upon profiling of the initial stage of external sorting, it seems
that this stage is overall CPU bound, with hotspots in comparetup_*
accounting for around 50% of CPU time; lets just call that too much,
since your exact
On Mon, 2005-10-03 at 23:25 +0200, Martijn van Oosterhout wrote:
Possible problem with caching:
if you're called by the system qsort, can you assume anything about the
order of the comparisons?
That applies only to the non-external sort case, which I'm not trying to
improve with these
Simon Riggs [EMAIL PROTECTED] writes:
AFAICS the following opportunities exist, without changing any of the
theoretical algorithms or the flexibility of definable datatypes:
1. tuplesort_heap_siftup and tuplesort_heap_insert make no attempt to
cache the values of keys that have been obtained
