On Wed, 2004-02-11 at 22:29, Jochem van Dieten wrote: > Chris Nolan wrote: > > Martijn Tonies wrote: > > > Additionally, it is an accepted fact that MySQL is faster than the > > mighty, mighty PostgreSQL. > > No, it is not. It is an accepted fact that MySQL is faster than > PostgreSQL for certain tasks. You're totally correct. I should have qualified my statement. As I mentioned earlier in this thread, I'm hanging out for new performance data on recent releases on the open source databases currently available, particularly for Firebird 1.5 and 2.0 (when each is released as stable) and PostgreSQL 7.4 (considering some of the excellent optimiser enhancements).
As I also mentioned, it's a terrible shame that the "big three" all require written permission for you to actually publish benchmark information in most cases. This is completely stupid, and gives people like me a few less means of engaging in discussions like this. > > > > The PostgreSQL developers say that they are faster > > than most commercial databases in their normal fsync mode. > > GreatBridge LLC claimed their PostgreSQL version was faster than > most commercial databases, in their specific benchmark. I am not > aware of any such claims from the current PGDG. > > > But there are a few gripes I have with comparing databases on > just performance: > - Performance data is not portable. You can't say that just > because one database is faster in one case, it will be faster in > another case too. > - Performance is overrated. For most applications, there is some > treshhold after which a database is 'fast enough'. I don't care > if I can serve 1200 or 1201 customers, if I only have 20 and grow > at a rate slower than Moore's Law. > - In most cases, you are not measuring database performance, but > DBA performance or developer performance. > Your last point above couldn't be more true. Thankfully, both MySQL and PostgreSQL have well developed APIs in a selection of languages. I'd dare say PostgreSQL has a slight advantage for some programs due to it's asynchronous query interface option and MySQL has the option of being embedded into your app for additional performance. > > >> I can think of a few others: > >> > >> - stored procedures (not finished with MySQL) > >> - triggers (not even on the roadmap with MySQL?) > >> - check constraints (please, Heiki?!) > >> > >> I'm a constraint-freak, if you like. I want my database to check the > >> data. In all sorts of possible ways... > >> > > > > Triggers are slated for the 5.1 timeframe, along with FK constraints for > > all table types (including BDB?). > > Check constraints have beem discussed in various presentations (at the > > 2003 MySQL conference, they were mentioned specifically with regard to > > MySQL's compliance to SQL92 and SQL:1999). > > I expect them in the 5.1 timeframe too, since you can implement > check constraints in triggers. But the question remains if we can > expect a stable 5.1 before 2006. Looking at 4.1's development cycle, it seems time between releases has contracted slighlty compared to 3.23 and 4.0. One must wonder about the impact of resources being devoted to the upkeep of 4.0, the stablisation of 4.1 and the development of 5.0 all at once though. Heikki would be the person to ask, as everyone knows of that the creator of InnoDB makes a hobby out of predicting relase dates for MySQL releases. Hopefully, we'll have PostgreSQL-style check constraints that are simply declared at table creation time and hopefully we'll also get PostgreSQL-style DEFAULT specification options instead of expressions that have to be evaluated statically at table creation. > > Jochem -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
