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

> > 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 thinking about changing this from a beta port to a -devel port
that I'll periodically update with snapshots.  I'll turn on -O6 for
the -devel port and -O2 for production for now.  If I don't hear of
any random bogons in the code I'll see if I can't increase it further
to -O3 and beyond at a slow/incremental rate.

Has there been any talk of doing incremental -snapshots of the code
base?  I've really fallen inlove with the concept for development.
Having incremental changes is much easier to cope with than massive
steps forward.

> > 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.

Hrm, I should go check the archives, but I thought what was used was
one step below -C[fF] and was used because of size concerns for
embedded databases.  My memory for what happens on mailing lists seems
to be fading though so I'll look it up.

> > 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.

Whoop, guess I won't do that.  :~)  Thanks.  -sc

-- 
Sean Chittenden