On Thu, 2005-12-01 at 23:31 -0800, David Lang wrote:
> > There are certain known cases when MySQL would not perform well - it is
> > easy to build the query using subqueries which would be horribly slow on
> > MySQL but decent on postgresql... but well writing application for
> > MySQL you would not write such query.
> I completely agree with the ideas that different databases will do
> different things well.
> what I would really like to see is a range of different tests proposed by
> the different teams to try and map out the areas where each does better
> then the other, and the areas where you absolutly should not use a
> particular database for that application
> I don't want a simplistic 'speed rateing' for each database, I would like
> to see a matrix, where one dimention is the tests and the other dimention
> is the database/hardware/tuneing combinations (this is assuming that the
> tuneing settings can fall into a relativly small number of variations,
> this is the OLTP vs data warehouse type of tuneing)
Well... That is common misunderstanding to be honest. If you would ask
people if MySQL can be used in data-warehouse applications some will say
sure it works great- MyISAM is very efficient it data loads and very
scan in full table scans, Archive Storage Engine we have in MySQL 5.0
is even faster.
Some others will tell you - hardly, because MySQL does not have sort
merge join or hash join, it also does not optimize many types of
SubSelect and can't use indexes on derived tables.
It is at the great extent the question of how you would design the
system and which technologies/features you're willing to use.
Some people for example for long while were saying certain applications
could not be written for MySQL due to the lack of Cursors or
Triggers... others were successfully using MySQL with exactly this type
This is why I'm mentioning you're best to define the task and try to get
best out of each database, designing the solution away which is optimal
for it - only this way you'll be bias free.
Actually there are way to many variables to be able to simply put
workloads in few groups and assume results will be relevant for wide
class of applications.
For example speaking about OLTP you instantly get the question about
size of database compared to size of memory and working set, number of
concurrent connections, transaction sizes, read write ratio, connection
persistence and a lot of other minor questions which however can affect
performance several time.
> > You also could take a look at http://benchw.sourceforge.net/
> thanks for the suggestions. as I noted above I would also be interested in
> suggestions for tests that hit the pathological situations in different
> databases, so if you have some test that you know that you do much better
> then postgres, let me have it (and bonus credibility to anyone who shows a
> benchmark that is bad for their own database :)
I've listed you number of cases which do not work with MySQL and we're
actually honestly have list of main limitations in our documentation:
Here is for example questions on subqueries
> > Let us know when you'll be testing something we'll be happy to help you
> > to get best results out of MySQL :)
> I appriciate it, I hand't head back from any MySQL folks (and nobody had
> posted to the /. thread) so I was getting ready to try and figure out what
> other mailing lists to hit.
Well... I guess they are to busy to follow slashdot discussions closely.
This list is much better place as well as forums
Peter Zaitsev, Senior Performance Engineer
MySQL AB, www.mysql.com