This definitely is the correct approach.
Actually, Daniel van Ham Colchete may not be as "all wet" as some
around here think. We've had previous data that shows that pg can
become CPU bound (see previous posts by Josh Berkus and others
regarding CPU overhead in what should be IO bound tasks).
In addition, we know that x86 compatible 64b implementations differ
enough between AMD and Intel products that it sometimes shows on benches.
Evidence outside the DBMS arena supports the hypothesis that recent
CPUs are needing more hand-holding and product specific compiling,
not less, compared to their previous versions.
Side Note: I wonder what if anything pg could gain from using SWAR
instructions (SSE*, MMX, etc)?
I'd say the fairest attitude is to do everything we can to support
having the proper experiments done w/o presuming the results.
Ron Peacetree
At 10:47 AM 12/11/2006, Chris Browne wrote:
>In order to prove what you want to prove, you need to run the
>benchmarks all on Gentoo, where you run with 4 categorizations:
>
> 1. Where you run PostgreSQL and GLIBC without any processor-specific
> optimizations
>
> 2. Where you run PostgreSQL and GLIBC with all relevant
> processor-specific optimizations
>
> 3. Where you run PostgreSQL with, and GLIBC without
> processor-specific optimizations
>
> 4. Where you run PostgreSQL without, and GLIBC with processor-specific
> optimizations
>
>That would allow one to clearly distinguish which optimizations are
>particularly relevant.
>
> > I'm not saying that Gentoo is faster than FC6. I just want to prove
> > that if you compile your software to make better use of your
> > processor, it will run faster.
> >
> > It might take a few days because I'm pretty busy right now at my
> > job.
>
>I expect that you'll discover, if you actually do these tests, that
>this belief is fairly much nonsense.
>
>- Modern CPUs do a huge amount of on-CPU self-tuning.
>
>- CPU features that could have a material effect tend to be unusable
> when compiling general purpose libraries and applications. GCC
> doesn't generate MMX-like instructions.
>
>- Database application performance tends to be I/O driven.
>
>- When database application performance *isn't* I/O driven, it is
> likely to be driven by cache management, which compiler options
> won't affect.
