From: Michael Stone <mstone+postgres@mathom.us>
To: pgsql-performance@postgresql.org
Subject: Re: New to PostgreSQL, performance considerations
Date: Mon, 11 Dec 2006 13:47:28 -0500
Message-ID: <20061211184726.GI16692@mathom.us> (raw)
In-Reply-To: <E1Gtplp-0004Ka-GM@elasmtp-junco.atl.sa.earthlink.net>
References: <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>
<60psaq5t94.fsf@dba2.int.libertyrms.com>
<E1GtolA-0008Fk-4R@elasmtp-banded.atl.sa.earthlink.net>
<20061211173105.GH16692@mathom.us>
<E1Gtplp-0004Ka-GM@elasmtp-junco.atl.sa.earthlink.net>
On Mon, Dec 11, 2006 at 01:20:50PM -0500, Ron wrote:
>(The validity of the claim has nothing to do with the skills or
>experience of the claimant or anyone else in the discussion. Only on
>the evidence.)
Please go back and reread the original post. I don't think the response
was unwarranted.
> It is a tad unfair and prejudicial to call claims that CPU
>optimizations matter to the performance of DB product "extraordinary".
>Evidence outside the DBMS field exists; and previous posts here show
>that pg can indeed become CPU-bound during what should be IO bound tasks.
>At the moment, Daniel's claims are not well supported. That is far
>different from being "extraordinary" given the current circumstantial
>evidence.
No, they're extraordinary regardless of whether postgres is CPU bound.
The question is whether cpu-specific compiler flags will have a
significant impact--which is, historically, fairly unlikely. Far more
likely is that performance can be improved with either a
non-cpu-specific optimization (e.g., loop unrolling vs not) or with an
algorithmic enhancement.
More importantly, you're arguing *your own* point, not the original
claim. I'll refresh your memory: "My Linux is not an Intel-AMD binary
compatible turtle like Fedora/RedHat/SUSE/... It's really important to
have your GLIBC compiled for your processor. It is essencial for
performance." You wanna draw the line between that (IMO, extraordinary)
claim and the rational argument that you're trying to substitute in its
place?
>[1] The evidence that arch specific flags matter to performance can
>be found as easily as recompiling your kernel or your
>compiler.
Then, please, point to the body of evidence. IME, the results of such
efforts aren't statistically all that signficant on most workloads. I'm
sure there are edge cases, but it's certainly not going to be on my top
ten things to look at when tuning a database system. (If your kernel's
cpu utilization is the bottleneck in your database, you've probably got
bigger problems than compiler flags can solve.) Where you get the real
big benefits in a (linux) kernel recompile is when you select code
that's specifically tuned for a particular processor--not from
arch-specific gcc flags--and those sorts of things are increasingly
moving toward boot-time autotuning rather than compile-time manual
tuning for obvious reasons.
Mike Stone
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: mstone+postgres@mathom.us
Subject: Re: New to PostgreSQL, performance considerations
In-Reply-To: <20061211184726.GI16692@mathom.us>
* 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