Re: Great Bridge benchmark results for Postgres, 4 others

Marc G. Fournier <scrappy@hub.org>

From: The Hermit Hacker <scrappy@hub.org>
To: Ned Lilly <ned@greatbridge.com>
Cc: Bryan White <bryan@arcamax.com>, PostgreSQL General <pgsql-general@postgresql.org>
Date: 2000-08-15T03:27:37Z
Lists: pgsql-general
On Mon, 14 Aug 2000, Ned Lilly wrote:

> 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...

do the tests only perform SELECTs?  Any UPDATEs or DELETEs will create
unclaimed space ...

> 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.

Actually, more RAM would permit you to increase both the -B parameters as
well as the -S one ... which are both noted for providing performance
increases ... -B more on repeative queries and -S on anything involving
ORDER BY or GROUP BY ...

Again, without knowing the specifics of the queries, whether either of the
above would make a difference is unknown ...