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