Re: [HACKERS] [PERFORM] Sun performance - Major discovery!

2003-10-14 Thread Tom Lane
Marko Karppinen <[EMAIL PROTECTED]> writes: > At least the --fast-math part causes problems, seeing that PostgreSQL > actually checks for the __FAST_MATH__ macro to make sure that it isn't > turned on. There might be other problems with Apple's flags, but I > think that the __FAST_MATH__ check s

Re: [HACKERS] [PERFORM] Sun performance - Major discovery!

2003-10-14 Thread Peter Eisentraut
Bruce Momjian writes: > Well, this is really embarassing. I can't imagine why we would not set > at least -O on all platforms. Looking at the template files, I see > these have no optimization set: > freebsd (non-alpha) I'm wondering what that had in mind: http://developer.postgresql.or

Re: [HACKERS] [PERFORM] Sun performance - Major discovery!

2003-10-14 Thread Marko Karppinen
On 8.10.2003, at 21:31, Bruce Momjian wrote: Well, this is really embarassing. I can't imagine why we would not set at least -O on all platforms. Looking at the template files, I see these have no optimization set: darwin Regarding Darwin optimizations, Apple has introduced a "-f

Re: [HACKERS] [PERFORM] Sun performance - Major discovery!

2003-10-14 Thread Peter Eisentraut
Marko Karppinen writes: > GCC sets __FAST_MATH__ even if you counter a -ffast-math with the > negating flags above. This means that it is not currently possible to > use the -fast flag when compiling PostgreSQL at all. Instead, you have > to go through all the flags Apple is setting and only pass

Re: [HACKERS] [PERFORM] Sun performance - Major discovery!

2003-10-13 Thread Bruce Momjian
Done as you suggested. --- Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > OK, patch attached and applied. It centralizes the optimization > > defaults into configure.in, rather than having CFLAGS= in the te

Re: [HACKERS] [PERFORM] Sun performance - Major discovery!

2003-10-13 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> writes: > OK, patch attached and applied. It centralizes the optimization > defaults into configure.in, rather than having CFLAGS= in the template > files. I think there's a problem here: > + # configure sets CFLAGS to -O2 for gcc, so this is only for non-gcc >

Re: [HACKERS] [PERFORM] Sun performance - Major discovery!

2003-10-09 Thread Andrew Sullivan
On Wed, Oct 08, 2003 at 02:31:29PM -0400, Bruce Momjian wrote: > Well, this is really embarassing. I can't imagine why we would not set > at least -O on all platforms. Looking at the template files, I see > these have no optimization set: I think gcc _used_ to generate bad code on SPARC if you s

Re: [HACKERS] [PERFORM] Sun performance - Major discovery!

2003-10-08 Thread Tom Lane
---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] [PERFORM] Sun performance - Major discovery!

2003-10-08 Thread Bruce Momjian
Tom Lane wrote: > Neil Conway <[EMAIL PROTECTED]> writes: > > On Wed, 2003-10-08 at 14:31, Bruce Momjian wrote: > >> Well, this is really embarassing. I can't imagine why we would not set > >> at least -O on all platforms. > > I believe that autoconf will automatically select -O2 (when CFLAGS isn

Re: [HACKERS] [PERFORM] Sun performance - Major discovery!

2003-10-08 Thread Christopher Kings-Lynne
Well, this is really embarassing. I can't imagine why we would not set at least -O on all platforms. Looking at the template files, I see these have no optimization set: freebsd (non-alpha) I'm wondering what that had in mind: http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/temp

Re: [HACKERS] [PERFORM] Sun performance - Major discovery!

2003-10-08 Thread Bruce Momjian
Peter Eisentraut wrote: > Bruce Momjian writes: > > > Well, this is really embarassing. I can't imagine why we would not set > > at least -O on all platforms. Looking at the template files, I see > > these have no optimization set: > > > freebsd (non-alpha) > > I'm wondering what that had

Re: [HACKERS] [PERFORM] Sun performance - Major discovery!

2003-10-08 Thread Jeff
On Wed, 8 Oct 2003, Neil Conway wrote: > ISTM the most legitimate reason for not enabling compilater > optimizations on a given compiler/OS/architecture combination is might > cause compiler errors / bad code generation. > > Can we get these optimizations enabled in time for the next 7.4 beta? It