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
