Re: Humor me: Postgresql vs. MySql (esp. licensing)

From: "Randolf Richardson, DevNet SysOp 29" <rr(at)8x(dot)ca>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Humor me: Postgresql vs. MySql (esp. licensing)
Date: 2003-11-19 18:48:57
Message-ID: Xns94386C01288D2rr8xca@200.46.204.72
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Thanks for this information, it's very helpful. I've included some
additional comments to further demonstrate how a qualified business planner
may look at this...

>> I'm preparing to enter a discussion with management at my company
>> regarding going forward as either a MySql shop or a Postgresql shop.
>
> - PostgreSQL supports constraints. MySQL doesn't; programmers need to
> take care of that from the client side

Wow. That's so rediculous that I don't want to believe it because
this feature is just so basic.

> - Define a 32-bit field in MySQL. Insert a 64-bit number instead. Common
> sense tells you the value would be rejected. Yet MySQL happily folds it
> in and carries on its merry way.

That's unacceptable. To me, this is a complete show-stopper because I
simply won't tolerate data loss due to an idiotic design flaw.

> - Triggers: PostgreSQL yes, MySQL no. Translates into more work for your
> MySQL developers in both creating your app and moving it forward with
> each rev.

There are also circumstances where PostgreSQL will create implicit
triggers, which means to me that MySQL must be lacking in some other
features as a result of not supporting this.

> - Transactions: We've been here before. Suffice to say, MySQL+InnoDB is
> almost there. Plain ol' MySQL doesn't have it, which tells you something
> about their philosophy towards database design.

It also indicates that Transactions are new to this product, and so
one may be better off with a more experienced group of developers who've
already earned their "battle scars" as is obviously the case with
PostgreSQL.

> - Speed: mHz for mHz, MySQL has PostgreSQL beat for simple searches.
> Once you start getting complex, PostgreSQL is competitive. I think this
> speed issue is overrated: over time, PostgreSQL has sped up and MySQL
> has slowed down which is pretty impressive, considering both have added
> features from their early versions.

Do you know of any published benchmarks for this? I need to convince
some people who are hell-bent on MySQL being fast for everything that
they're mis-informed, and they refuse to take anyone's word for it.

> - Scalability: MySQL dies before PostgreSQL does. PostgreSQL under
> extreme load may slow down, but it'll finish. MySQL simply gives up.
[sNip]

I've experienced this very problem with MySQL actually. It seems that
Apache James (an open source Java-based SMTP/POP3 mail server) running on
FreeBSD will trigger this problem very quickly as soon as multiple users
attempt to send large (greater than 10 MBs) file attachments -- perhaps
JDBC is part of the problem, but in the Apache James error logs there is
indication of MySQL connectivity problems (also during busy times on
systems sending approximately 500,000 eMails per day).

--
Randolf Richardson - rr(at)8x(dot)ca
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
http://www.8x.ca/

This message originated from within a secure, reliable,
high-performance network ... a Novell NetWare network.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Lamar Owen 2003-11-19 18:49:17 Re: SuSE RPMs available for PostgreSQL 7.4
Previous Message Michael Meskes 2003-11-19 18:44:40 Re: Problem with exec sql include