Re: [PERFORM] A Better External Sort? - Mailing list pgsql-hackers

From Martijn van Oosterhout
Subject Re: [PERFORM] A Better External Sort?
Date
Msg-id 20051004143041.GH17589@svana.org
Whole thread Raw
In response to Re: [PERFORM] A Better External Sort?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Oct 04, 2005 at 10:06:24AM -0400, Tom Lane wrote:
> Martijn van Oosterhout <kleptog@svana.org> writes:
> > I'm using: gcc (GCC) 3.3.5 (Debian 1:3.3.5-13)
>
> I don't know what the units of this number are, but it's apparently far
> too gcc-version-dependent to consider putting into our build scripts.
> Using gcc version 4.0.1 20050727 (current Fedora Core 4 compiler) on
> i386, and compiling tuplesort.c as you did, I find:
>     -O2: warning goes away between 800 and 900
>     -O3: warning is always there (tried values up to 10000000)
> (the latter behavior may indicate a bug, not sure).

Facsinating. The fact that the warning goes away if you don't specify
-finline-limit seems to indicate they've gotten smarter. Or a bug.
We'd have to check the asm code to see if it's actually inlined or
not.

Two options:
1. Add -Winline so we can at least be aware of when it's (not) happening.
2. If we can't get gcc to reliably inline, maybe we need to consider
other options?

In particular, move the isNull test statements out since they are ones
the optimiser can use to best effect.

Add if we put in -Winline, it would be visible to users while
compiling so they can tweak their own build options (if they care).
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: Inherited indexes.
Next
From: Tom Lane
Date:
Subject: Re: Vacuum and Transactions