Date: Mon, 11 Dec 2006 13:47:28 -0500
From: Michael Stone <mstone+postgres@mathom.us>
Subject: Re: New to PostgreSQL, performance considerations
In-reply-to: <E1Gtplp-0004Ka-GM@elasmtp-junco.atl.sa.earthlink.net>
To: pgsql-performance@postgresql.org
Mail-followup-to: pgsql-performance@postgresql.org
Message-id: <20061211184726.GI16692@mathom.us>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-disposition: inline
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>
User-Agent: Mutt/1.5.13 (2006-08-11)

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