Re: Humor me: Postgresql vs. MySql (esp. licensing) - Mailing list pgsql-general
From | Randolf Richardson, DevNet SysOp 29 |
---|---|
Subject | Re: Humor me: Postgresql vs. MySql (esp. licensing) |
Date | |
Msg-id | Xns94386C01288D2rr8xca@200.46.204.72 Whole thread Raw |
In response to | Humor me: Postgresql vs. MySql (esp. licensing) ("John Wells" <jb@devsea.com>) |
Responses |
Re: Humor me: Postgresql vs. MySql (esp. licensing)
|
List | 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@8x.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.
pgsql-general by date: