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
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.