Thread: MySQL comparison

MySQL comparison

From
Bruce Momjian
Date:
For people interesting in MySQL's status, here is a posting from the
recent Red Hat/Slashdot discussion.  It seems to lay things out pretty
clearly.

---------------------------------------------------------------------------

Remaining SQL92 issues: subselects in SELECT, subselects in FROM (also
called projections), subselects in WHERE. Each can be thought of as a
seperate implementation issue. Views. Updateable views. Foreign keys.
Constraints, in particular referential integrity constriants. Required
transactions - this is part of every SQL standard, it's a base
assumption. SELECT INTO table. Temp tables. Domains. Stored procedures
and triggers aren't standardized, but every major DB has them, and
they're demanded out in the real world -- add them to the list.

After adding all the above, MySQL will need some serious (read:
light-years of) development on their query analyzer. MySQL does well on
simple selects but performs notably slow on complex queries. Which is
hardly a surprise given their assumptions, design goals, and evangelism.

InnoDB needs more testing, and it needs to continue to grow. I have full
faith in Heikki Turri's skill.

I cannot say the same for the other MySQL AB developers. They have spent
the last few years stonewalling efforts to turn MySQL into a real DB.
They proclaimed that transactions were bad, table locks were as fine
grained as you ever needed, constraints should be handled by the client
application, and that stored procedures existed because other vendors
couldn't write fast SQL parsers (thus showing a failure to understand
the difference between declarative and procedural programming). Now,
demands from their larger customers, plus products from people like
Heikki, appear to be forcing MySQL AB forwards towards ACID compliance.
So, no, I do not trust MySQL AB to implement these things quickly and
effectively.

If you read their TODOs, you can see most of this stuff in targeted for
4.1. That's 2 major revs away. What will Postgres be doing in that time?

--
Bruce Momjian                        |  http://candle.pha.pa.us
pgman@candle.pha.pa.us               |  (610) 853-3000
+  If your life is a hard drive,     |  830 Blythe Avenue
+  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Re: MySQL comparison

From
Daniel Åkerud
Date:
> What will Postgres be doing in that time?

Eager data replication with no performance penalty? *haa-haa* ;)

Daniel Åkerud


Re: MySQL comparison

From
Mike Mascari
Date:
Daniel Åkerud wrote:
>
> > What will Postgres be doing in that time?
>
> Eager data replication with no performance penalty? *haa-haa* ;)
>
> Daniel Åkerud

Of course, fgrep is even faster! ;-)

Mike Mascari
mascarm@mascari.com