Slashdot Mirror

There is no comparison. Google Chrome is slow and badly behaved and Firefox is not. I don't understand all these reports that say "Chrome is so much faster than Firefox" when I routinely see a Chrome install with zero add-ons on a particular machine with recently cleared history and caches consistently slow down during use worse than a fresh Firefox install with ad blocking add-ons on the exact same machine.

There was also no dishonesty in my statements--I stated that I did not know if the option existed which is not the same as "other browsers don't have that." I do not use non-Firefox browsers on a regular basis.

I'd love to see that list of failures running on InnoDB with a modern version of MySQL. Not to be argumentative, but it can't be that long of a list.

cf http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL#MySQL:InnoDB

MDI is a terrible UI. All modern software is moving away from it.

I wasn't sure about this, and finally I agree...

MDI vs SDI

Especially when we think about multiple monitor and desktops. And now window managers handle the grouping quite well in the task bar.

It's not 2000 anymore. 99% of the problems people have historically with MySQL are simply not present in recent production versions. PostgreSQL and MySQL roughly have feature parity nowadays, Stop treating MySQL as if it's some toy. WikiVS has a good, up-to-date comparison: http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL

Big emphasis on the "roughly". The features may look the same as tick points on a list, but when you actually try to use them, vast differences show up. Roughly bundled-together features without a comprehensive plan is what it looks like to me. For example, no referential transparency or transitive closure. You can't just nest expressions, views, function calls and procedure calls transparently. You can't alias temp tables in procedures, etc... Lots of odd restrictions and "can't get there from here" scenarios.

I also find it amusing that an AC below complains about "how many storage engines"? Whoosh, that's the sound of the point flying over his head.

By the way, I'm not dissing PostgreSQL in any way, I think it's great. But it's about time some meaningless mantras stop being chanted.

Yeah, we shouldn't expect that old bugaboo "conceptual integrity" to intrude on modern software design, right? Can't use full-text indexing and foreign key constraints on the same table? What kind of compulsive freak would want that, anyway...?

2000 has called, they want their knee-jerk mantras back: http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL

It's not 2000 anymore. 99% of the problems people have historically with MySQL are simply not present in recent production versions. PostgreSQL and MySQL roughly have feature parity nowadays, Stop treating MySQL as if it's some toy. WikiVS has a good, up-to-date comparison: http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL

I also find it amusing that an AC below complains about "how many storage engines"? Whoosh, that's the sound of the point flying over his head.

By the way, I'm not dissing PostgreSQL in any way, I think it's great. But it's about time some meaningless mantras stop being chanted.

That is possible if I read this right. http://it.toolbox.com/blogs/php-bsd-me/the-mysql-license-8922
It would leave any closed source licensed versions dependent on Oracle or force them to carefully separate out their code from mysql so they can use the forked version.

I would use Postgresql http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL since it's standards compliant, feature full and is fast if properly configured.

However, they've now said that, since this hasn't worked so well in practice, the next version of PostgreSQL WILL include direct, built-in support for basic replication, as well as making sure that heavyweight, third-party replication solutions are still supported.

Well, wake me when it's there. MySQL still gets bashed for its historical lack of transactions, so if Postgres wants credit for something, it can at least implement it. Last I checked, it was supposed to be in 8.4, then it wasn't, then it was supposed to be in 8.5, and if memory serves, it's slipping again.

Either way, I don't think these replication issues are a good enough reason to use MySQL instead. Worst case scenario, there ARE good replication options for PostgreSQL.

So which one of those solutions is:

1. Easy to configure (as in, no harder than MySQL replication).
2. Scales linearly (Slony-I scales quadratically, which is why you can't get beyond a few nodes)
3. Can add a slave node without downtime
4. Can handle, gracefully, a failure of the master node
5. Can do master-master replication
6. Can do statement-based replication and also log-based replication (to support autogenerated keys, rand(), etc.)

MySQL replication supports all of the above, and has for years now. Postgres has some serious catching up to do in this area.

I'm sorry, but Slony-I is not a serious replication solution.

I believe the PostgreSQL devs themselves have said as much (officially, on their site). They've also said that the reason for this situation is that the project had previously taken the stance that it should not include its own replication, but should instead allow third-parties to implement replication as they see fit.

However, they've now said that, since this hasn't worked so well in practice, the next version of PostgreSQL WILL include direct, built-in support for basic replication, as well as making sure that heavyweight, third-party replication solutions are still supported.

Either way, I don't think these replication issues are a good enough reason to use MySQL instead. Worst case scenario, there ARE good replication options for PostgreSQL. There are even third-party products out there that can replicate from Oracle to PostgreSQL. Interestingly, that particular solution was targeted at MySQL first, as it has similar issues.

The latest version of each have brought the two much closer in terms of performance and features. Historically, MySQL has been regarded as faster for simple querying and DML statements, but lacked full ACID compliance. PostgreSQL supported more advanced features like a PL/SQL style procedure language, transaction support, and data compression.

Today, the big difference is PostgreSQL is considered better on higher-end hardware with concurrent I/O support and better multi-core support. MySQL is considered better on clusters of lower-end hardware. There is a Wiki comparing the two in much better detail.

Personally, I work with both in large production systems and can fill a few pages on likes and gripes. I'm on MySQL 4.1, so concurrency is a concern, and PostgreSQL's replication is a pain. Unless you're trying to solve a problem MySQL can't satisfy, I wouldn't switch for the sake of change. Your time is probably better spent upgrading to MySQL 5.1.

PostgreSQL vs. MySQL WIki

Seems to be features only, no performance.