Re: Great Bridge benchmark results for Postgres, 4 others
От | The Hermit Hacker |
---|---|
Тема | Re: Great Bridge benchmark results for Postgres, 4 others |
Дата | |
Msg-id | Pine.BSF.4.21.0008150023480.92127-100000@thelab.hub.org обсуждение исходный текст |
Ответ на | Re: Great Bridge benchmark results for Postgres, 4 others (Ned Lilly <ned@greatbridge.com>) |
Список | 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 ...
В списке pgsql-general по дате отправления: