From: Chris Browne <cbbrowne@acm.org>
To: pgsql-performance@postgresql.org
Subject: Re: New to PostgreSQL, performance considerations
Date: Mon, 11 Dec 2006 10:47:51 -0500
Message-ID: <60psaq5t94.fsf@dba2.int.libertyrms.com> (raw)
References: <8a0c7af10612101141n2c7727c3r2f92345753960808@mail.gmail.com>
<430d92a20612101336r3de8862coe618277fccb4006a@mail.gmail.com>
<8a0c7af10612101702i49b5a533v4a2300d90d9dae6b@mail.gmail.com>
<20061211021847.GE16692@mathom.us>
<8a0c7af10612110305u305124b2v3d63491b5f57a86b@mail.gmail.com>
<87u002mv49.fsf@wolfe.cbbrowne.com>
<8a0c7af10612110531sbb019ck259fb16d131fdb50@mail.gmail.com>
daniel.colchete@gmail.com ("Daniel van Ham Colchete") writes:
> You are right Christopher.
>
> Okay. Let's solve this matter.
>
> What PostgreSQL benchmark software should I use???
pgbench is one option.
There's a TPC-W at pgFoundry
(<http://pgfoundry.org/projects/tpc-w-php/;).
There's the Open Source Database Benchmark.
(<http://osdb.sourceforge.net/;)
Those are three reasonable options.
> I'll test PostgreSQL 8.1 on a Fedora Core 6 and on a Gentoo. I'll get
> the same version FC6 uses and install it at my Gentoo. I'll use the
> same hardware (diferent partitions to each).
Wrong approach. You'll be comparing apples to oranges, because Gentoo
and Fedora pluck sources from different points in the source code
stream.
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.
--
output = reverse("ofni.secnanifxunil" "@" "enworbbc")
http://linuxdatabases.info/info/sgml.html
"very few people approach me in real life and insist on proving they
are drooling idiots." -- Erik Naggum, comp.lang.lisp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: cbbrowne@acm.org
Subject: Re: New to PostgreSQL, performance considerations
In-Reply-To: <60psaq5t94.fsf@dba2.int.libertyrms.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox