I rate PostgreSQL quite highly, and my friends who use it say it is greatly improved now. I don't think that it is a shocking statement to say that a simple four-way join took ten times longer, though. It just underlines how careful one has to be with porting a database from one platform to another.

Until recently I had the offending execution plan, but I can't put my hands on it. I was writing the database for a J2E/postreSQL application. Just because the development tools were better in SQL Server, I wrote the first cut in SQL Server, and stocked it with realistic data. I ran test timings on all the SQL Calls. I then ported the database to PostgreSQL (it was surprisingly simple) using the EMS PostgreSQL tools. I then ran the same timings. The PostgreSQL database was hosted on Linux (I also tried the Windows version with similar results) on hardware that was pretty-well identical to the SQL Server version. The purpose of the timings was to check that the indexing I'd used for SQL Server was appropriate for PostgreSQL, and to flag up any problems. The problem with the four-way joins was somewhat embarrassing as I'd had an argument with the Devs over denormalization. I'd demonstrated, using SQL Server, that there was no measurable difference on SQL Server between a fully-normalized NAD subsystem that involved a four-way join and a denormalized two-way join. I was not happy to find out that the same wasn't true with PostgreSQL. I put the offending query and plan on some PostgreSQL sites and asked PostgreSQL experts, and did everything they suggested, but I never got the speed up to SQL Server. If I remember right, the problem was due to the postgreSQL indexes not 'covering' the query in the same way as SQL Server.

PostgreSQL deserves our support as being the only free open source relational database that is community-owned and published under a BSD Licence. I'm happy to recommend it where the use of SQL Server is not appropriate for some reason, but it is unfair on PostgreSQL to compare it directly with an industrial-strength commercial database such a SQL Server; it is hardly surprising to find that there are occasions where it doesn't match up. It has improved enormously in the time since I used it.