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

Statements like these can not be reasonably interpreted in any manner
_except_ that of presuming the results:

"I expect that you'll discover, if you actually do these tests, that
this belief  (that using arch specific compiler options lead to
better performing SW) is fairly much nonsense."

"...IMO a waste of time..."

etc

The correct objective response to claims w/o evidence is to request
evidence, and to do everything we can to support it being properly
gathered.  Not to try to discourage the claimant from even trying by
ganging up on them with multiple instances of Argument From Authority
or variations of Ad Hominem attacks.
(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.)

  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.

Let's also bear in mind that as a community project, we can use all
the help we can get.  Driving potential resources away is in
opposition to that goal.

[1] The evidence that arch specific flags matter to performance can
be found as easily as recompiling your kernel or your
compiler.   While it certainly could be argued how "general purpose"
such SW is, the same could be said for just about any SW at some
level of abstraction.

Ron Peacetree


At 12:31 PM 12/11/2006, Michael Stone wrote:
>On Mon, Dec 11, 2006 at 12:15:51PM -0500, Ron wrote:
>>I'd say the fairest attitude is to do everything we can to support
>>having the proper experiments done w/o presuming the results.
>
>Who's presuming results?[1] It is fair to say that making
>extraordinary claims without any evidence should be discouraged.
>It's also fair to say that if there are specific things that need
>cpu-specific tuning they'll be fairly limited critical areas (e.g.,
>locks) which would probably be better implemented with a hand-tuned
>code and runtime cpu detection than by magical mystical compiler invocations.
>
>Mike Stone
>
>[1] I will say that I have never seen a realistic benchmark of
>general code where the compiler flags made a statistically
>significant difference in the runtime. There are some particularly
>cpu-intensive codes, like some science simulations or encoding
>routines where they matter, but that's not the norm--and many of
>those algorithms already have hand-tuned versions which will
>outperform autogenerated code. You'd think that with all the talk
>that the users of certain OS's generate about CFLAG settings,
>there'd be some well-published numbers backing up the hype. At any
>rate if there were numbers to back the claim then I think they could
>certainly be considered without prejudice.