Re: Optimization levels when compiling PostgreSQL... - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Optimization levels when compiling PostgreSQL...
Date
Msg-id 15789.1031625648@sss.pgh.pa.us
Whole thread Raw
In response to Optimization levels when compiling PostgreSQL...  (Sean Chittenden <sean@chittenden.org>)
Responses Re: Optimization levels when compiling PostgreSQL...  (Sean Chittenden <sean@chittenden.org>)
Re: Optimization levels when compiling PostgreSQL...  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Sean Chittenden <sean@chittenden.org> writes:
> The size difference between -O and -O3 is only 200K or so... does
> anyone think that it'd be safe to head to -O6 on a wide scale?

Dunno.  I'm not aware of any bits of the code that are unportable enough
to break with max optimization of any correct compiler.  But you might
find such a bug.  Or a bug in your compiler.  Are you feeling lucky
today?

My feeling is that gcc -O2 is quite well tested with the PG code.
I don't have any equivalent confidence in -O6.  Give it a shot for
beta-testing, for sure, but I'm iffy about calling that a
production-grade database release...

> I'm even thinking about going so far as to have flex required for the
> build dependencies and setting -Cf or -CF for building the scanner
> (need to check the archives for which turned out to be faster).

Um, didn't we do that stuff already in the standard build?  AFAIK
you cannot build PG with any lexer except flex, and Peter already
hacked the flags.

> I'm also tinkering with the idea of automatically turn off fsync if
> optimize is set.

No-bloody-way.  Trusting your compiler is an entirely separate issue
from whether you trust your disk hardware, power source, etc.  Puh-leez
do not muddy the waters by introducing a port-specific variation in
choices that only the DBA of a particular installation should make.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Christopher Kings-Lynne"
Date:
Subject: Re: Proposal: Solving the "Return proper affected tuple
Next
From: Curt Sampson
Date:
Subject: Re: problem with new autocommit config parameter and jdbc