Date: Wed, 14 Mar 2007 20:05:50 +0100 From: Alban Hertroys <dalroi@solfertje.student.utwente.nl> To: Steven Hartland <killing@multiplay.co.uk> Cc: freebsd-stable <freebsd-stable@freebsd.org> Subject: Re: FreeBSD mysql Benchmark on 4BSD/ULE scheduler and i386/amd64 Message-ID: <F9AC3DF0-F887-4A4C-A1F9-D60AF105FA50@solfertje.student.utwente.nl> In-Reply-To: <009c01c765d3$759f0890$b3db87d4@multiplay.co.uk> References: <20070313154729.1ec6abb7@DELOREAN.manuelmartini.it><20070313194206.GA5957@crodrigues.org><20070313195756.GA11679@xor.obsecurity.org><20070313211908.59de6504@DELOREAN.manuelmartini.it><20070313214559.GB13079@xor.obsecurity.org> <330A1347-2309-417E-83B5-5B2CE005B9C8@solfertje.student.utwente.nl> <009c01c765d3$759f0890$b3db87d4@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F9AC3DF0-F887-4A4C-A1F9-D60AF105FA50>