On Tue, Feb 07, 2006 at 07:06:26AM +0100, Nemanja Corlija wrote: > On 2/7/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
> > Did you happen to do an analyze? > Nope. All databases are run as default as possible. And, they all get > same scripts to execute. Then your results for PostgreSQL are utterly meaningless. (And in this case, the poor performance reflects poorly on you, the DBA, not on PostgreSQL.) > > What changes have you made to the default postgresql.conf? > None. Then your test results are bogus. Last I heard, the default value in postgresql.conf were intended to simply work AT ALL on the widest possible range of hardware, operating systems, etc., and are NOT recommended values for any actual production use. Yes, I that sounds very foolish of the PostgreSQL folks to me too, but there you have it. Using PostgreSQL properly REQUIRES that you modify those settings. > Sure, I could do that. But then I'd also need to tune all other > databases to make things fair and that's not really what I intended to > do here. I want to keep things as "out of the box" as possible. The above is not exactly "tuning", it is basic "Running PostgreSQL 101" type stuff. Look at it this way: Different databases have different installation requirements. Editing postgresql.conf and collecting statistics with vacuum analyze are simply part of the required install procedure for PostgreSQL. If you don't do the basic stuff like that, your database is simply misconfigured, and any performance results you generate are worthless - because in the real world, NO ONE with any clue at all would ever run their database that way. Minimally, you need to install and configure each of the databases you're benchmarking in the manner expected of a competent but non-expert user of that tool. Naturally this various for different databases. If you find the process of properly installing and configuring the database software overly complicated or poorly documented, then that's a perfectly legitimate complaint, but it has nothing to do with performance benchmarking. -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/
