Re: New to PostgreSQL, performance considerations - Mailing list pgsql-performance

From Michael Stone
Subject Re: New to PostgreSQL, performance considerations
Date
Msg-id 20061211184726.GI16692@mathom.us
Whole thread Raw
In response to Re: New to PostgreSQL, performance considerations  (Ron <rjpeace@earthlink.net>)
Responses Re: New to PostgreSQL, performance considerations  (Ron <rjpeace@earthlink.net>)
List pgsql-performance
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

pgsql-performance by date:

Previous
From: "Luke Lonergan"
Date:
Subject: Re: Looking for hw suggestions for high concurrency
Next
From: Michael Stone
Date:
Subject: Re: New to PostgreSQL, performance considerations