On 23-Sep-06, at 9:49 AM, Guido Neitzer wrote:
On 9/23/06, Dave Cramer <[EMAIL PROTECTED]> wrote:
1) The database fits entirely in memory, so this is really only
testing CPU, not I/O which should be taken into account IMO
I don't think this really is a reason that MySQL broke down on ten or
more concurrent connections. The RAM might be, but I don't think so
too in this case as it represents exactly what we have seen in similar
tests. MySQL performs quite well on easy queries and not so much
concurrency. We don't have that case very often in my company ... we
have at least ten to twenty connections to the db performing
statements. And we have some fairly complex statements running very
often.
Nevertheless - a benchmark is a benchmark. Nothing else. We prefer
PostgreSQL for other reasons then higher performance (which it has for
lots of situations).
I should make myself clear. I like the results of the benchmark. But
I wanted to keep things in perspective.
Dave
cug
--
PostgreSQL Bootcamp, Big Nerd Ranch Europe, Nov 2006
http://www.bignerdranch.com/news/2006-08-21.shtml
---------------------------(end of
broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that
your
message can get through to the mailing list cleanly
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
