At 07:06 PM 12/15/2006, Michael Stone wrote:
>On Fri, Dec 15, 2006 at 12:24:46PM -0500, Ron wrote:
>>ATM, the most we can say is that in a number of systems with modest
>>physical IO subsystems
>
>
>So I reran it on a 3.2GHz xeon with 6G RAM off a ramdisk; I/O ain't
>the bottleneck on that one. Results didn't show didn't show any
>signficant gains regardless of compilation options (results hovered
>around 12k tps). If people want to continue this, I will point out
>that they should make sure they're linked against the optimized
>libpq rather than an existing one elsewhere in the library path.
>Beyond that, I'm done with this thread. Maybe there are some gains
>to be found somewhere, but the testing done thus far (while limited)
>is sufficient, IMO, to demonstrate that compiler options aren't
>going to provide a blow-your-socks-off dramatic performance improvement.
AFAICT, no one has stated there would be a "blow-your-socks-off
dramatic performance improvement" for pg due to compilation
options. Just that there might be some, and there might be some that
are arch specific.
So far these experiments have shown
= multiple instances of a ~30-35% performance improvement going from
-O0 to --O3
= 1 instance of arch specific options hurting performance when
combined with -O3
= 1 instance of arch specific options helping performance on an OS
that only one person has tested (Gentoo Linux)
= that a 2.33 GHz C2D Mac laptop (under what OS?) with a typical
laptop modest physical IO subystem can do ~2100tps
= that pg has a "speed limit" on a 3.2GHz Xeon (which kind?) with 6G
RAM off a ramdisk (under what OS?) of ~12K tps
(I'd be curious to see what this limit is with better CPUs and memory
subsystems)
Note that except for the first point, all the other results are
singletons that as of yet have not been reproduced.
The most important "gain" IMO is Knowledge, and I'd say there is
still more to learn and/or verify IMHO. YMMV.
Ron Peacetree
