On Tue, 30 Sep 2003, David Griffiths wrote:

> This is all part of a "migrate away from Oracle" project. We are looking at
> 3 databases -
> MySQL (InnoDB), Postgres and Matisse (object oriented). We have alot of
> queries like this
> or worse, and I'm worried that many of them would need to be re-written. The
> developers
> know SQL, but nothing about tuning, etc.

There's a movement at my company to ditch several commercial db's in favor
of a free one.  I'm currently the big pg fan around here and I've actually
written a rather lengthy presentation about pg features, why, tuning, etc.
but another part was some comparisons to other db's..

I decided so I wouldn't be blinding flaming mysql to give it a whirl and
loaded it up with the same dataset as pg.  First thing I hit was lack of
stored procedures.   But I decided to code around that, giving mysql the
benefit of the doubt.  What I found was interesting.

For 1-2 concurrent
'beaters' it screamed. ultra-fast.  But.. If you increase the concurrent
beaters up to say, 20 Mysql comes to a grinding halt.. Mysql and the
machine itself become fairly unresponsive.  And if you do cache unfriendly
queries it becomes even worse.   On PG - no problems at all. Scaled fine
and dandy up.  And with 40 concurrent beaters the machine was still
responsive.  (The numbers for 20 client was 220 seconds (pg) and 650
seconds (mysql))

So that is another test to try out - Given your configuration I expect you
have lots of concurrent activity.


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
      joining column's datatypes do not match

Reply via email to