Re: Optimization levels when compiling PostgreSQL...

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