On Mar 14, 2007, at 1:55, Steven Hartland wrote:
Alban Hertroys wrote:
Sorry, couldn't resist...
Being a troll?
I don't troll, I'm not like that.
I have a problem with how mysql often gets falsely marketed as the
fastest database. The subject just pushed the right buttons, sorry
about that. Apparently I was vaguely aware of that, or I wouldn't
have written that.
This being mysql, the number of processors isn't going to matter
much, no matter how many connections you have. Mysql doesn't scale
very well to multiple cpu's.
You seem to have been paying no attention at all to any of the mysql
performance benchmarks and optimisation efforts that have being going
on recently.
I keep track of this ML, this was the first time I've seen the topic
come up. If this started somewhere else, then sorry, didn't know
about it.
I have to admit I was confused about the purpose of the benchmark. I
am so used to seeing (usually bad) comparison benchmarks between
mysql and postgres that I mistook this for one. That's probably due
to me being a postgresql mailing list regular.
Not to say that PostgreSQL is the ultimate benchmark instead of
mysql, just a better one. Of course they both have their uses, but
IMO mysql is loosing terrain fast.
Any benchmark which looks to closely emulate "real life work" is
valid, just be because "you" dont use or like a particular product
doesnt make it any less suitable for testing / benchmarking. I'm sure
if you took a survey of how many people are using mysql vs PostgreSQL
it would show that the former is much more popular DB. No this doesnt
make it better but it does make it a more suitable candidate for
performance work as the benefits will benefit more people and more
systems.
Well, that depends on what you're trying to benchmark of course.
It keeps amazing me that people choose a product based on how many
people use it, instead of how well it works. That goes for mysql vs
postgresql as much as for linux vs freebsd.
In that way benchmarks like these are useful; it shows that freebsd
outperforms linux if you use mysql. It shows that what most people
chose is not necessarily the best choice.
What I would have liked to see was a graph showing that postgresql on
FreeBSD performs both better than MySQL on either platform and better
than postgresql on linux (all of which are quite theoretical at this
point).
Combined into a well written and well argumented article (that is
easy to stumble upon preferably), that may just help a little to get
people off that ridiculous idea.
It also has a "known" bottleneck to its performance on FreeBSD see
earlier comments in other threads by Kris on this which clearly
limits any benefit gained from using it as a benchmark.
This is unfortunate, and now you mention it I do have a vague
recollection of a problem discussion. I'll have to read up on that
once I have the time to, and I hope to be able to cross-reference
that to the pg-general ML.
In real life situations, I usually find that a database problem can
often be rewritten into a more optimal design once you move from
mysql to postgresql. I use both, although I vastly prefer postgresql.
Where you hit a brick wall with mysql, you can usually move on in
postgresql by putting data into materialised views, using smarter
subqueries, stored procedures, triggers, contrib packages like ltree,
etc.
So, even though there is apparently a bottleneck with it on FreeBSD
(not too severe, I hope), the end result may still be better than
when using mysql.
I realise this is starting to get off topic, I suggest replies should
focus on the first half of my reply.
--
Alban Hertroys
"If you can't see the forest through the trees,
cut the trees and you'll see there is no forest"
!DSPAM:74,45f847759413227012565!
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
