Re: Great Bridge benchmark results for Postgres, 4 others

Bryan, see my earlier post re: ODBC... will try and answer your other questions
here...

> 2) Postgres has the 'vacuum' process which is typically run nightly which if
> not accounted for in the benchmark would give Postgres an artificial edge.
> I don't know how you would account for it but in fairness I think it should
> be acknowledged. Do the other big databases have similar maintenance
> issues?

Don't know how this would affect the results directly. The benchmark app builds
the database clean each time, and takes about 18 hours to run for the full 100
users (for each product). So each database created was coming in with a clean
slate, with no issues of unclaimed space or what have you...

> 3) The test system has 512MB RAM. Given the licensing structure and high
> licencing fees, users have an incentive to use much larger amounts of RAM.
> Someone who can only afford 512MB probably can't afford the big names
> anyway.

True, and it's a fair question how each database would make use of more RAM. My
guess, however, is that it wouldn't boost the transactions per second number -
where more RAM would impact the numbers would be more sustained performance in
higher numbers of concurrent users. Postgres and the two proprietary databases
all kept fairly flat lines (good) as the number of users edged up. We plan to
continuously re-run the tests with more users and bigger iron, so as we do that,
we'll keep the community informed.

> 4) The artical does not mention the Speed or Number of CPUs or anything
> about the disks other than size. I can halfway infer that they are SCSI but
> how are they layed out.

Yep, the disks were 2x 18 gig Wide SCSI, hot pluggable. The CPU was a single
600 Mhz Pentium III.

> I am not trying to tear the benchmark down. Just wanting it more immune to
> such attempts.

Not a problem, happy to try and answer any questions. Again, this is not
intended as a categoric statement of Postgres' superiority in any and all
circumstances. It's an attempt to share our research with the community on our
best attempt at a first-pass "apples to apples" comparison among the 5
products. I should also note that since the source to the benchmarks was not
available to us, including in many cases even the SQL queries, we couldn't do
much in the way of "tuning" that you'd normally want your DBA to do. Although
again, that limitation applied for all five products.

Regards,
Ned