Or understanding that commercial databases are the only way to go.
1. PostgreSQL can do materialized views, even though they don't call it that. Google postgresql materialized views
2. MySQL can run a fantastic DW. I know because I ran a 5T MySQL DW for 7 years, even before it was catching on(and had lots of warts). I had 30k users for the BI I was providing and it ran like a top. It all comes down to the skill(and dedication) of your DBA. The raw speed and small format of MyISAM makes it ideal for this role, but usage has to be properly managed. MyISAM table locking makes this a fun challenge, but quite doable.
3. Query speed is roughly equivalent between PG 8.2 and MySQL 5.0. Some things are better in each due to the optimizers, but it essentially ends up a wash. However, with concurrent updates and the negative impact this has on the MySQL query cache on write heavy DBs PG is often better. PG 8.3 will be far superior to MySQL in _overall_ write/read performance in an OLTP env. PG 8.2 in the past was not as good here due to the transaction overhead of being an _actual_ 100% ACID MVCC+ database. On small to moderate hardware MySQL and PostgreSQL will smoke any commercial DB except maybe SQL Server since it doesn't do MVCC.
It's all a trade off. To say one is better than another means you're not factoring in the application and needs of the user. It pains me to say so, but sometimes I have to tell the customer . . . "Your best bet is SQL Server". :) However, if I'm staying more than a few months I'd much rather see them use PostgreSQL in most situations, and even MySQL in a few.
You must be incapable of speeling
Or understanding that commercial databases are the only way to go.
1. PostgreSQL can do materialized views, even though they don't call it that. Google postgresql materialized views
2. MySQL can run a fantastic DW. I know because I ran a 5T MySQL DW for 7 years, even before it was catching on(and had lots of warts). I had 30k users for the BI I was providing and it ran like a top. It all comes down to the skill(and dedication) of your DBA. The raw speed and small format of MyISAM makes it ideal for this role, but usage has to be properly managed. MyISAM table locking makes this a fun challenge, but quite doable.
3. Query speed is roughly equivalent between PG 8.2 and MySQL 5.0. Some things are better in each due to the optimizers, but it essentially ends up a wash. However, with concurrent updates and the negative impact this has on the MySQL query cache on write heavy DBs PG is often better. PG 8.3 will be far superior to MySQL in _overall_ write/read performance in an OLTP env. PG 8.2 in the past was not as good here due to the transaction overhead of being an _actual_ 100% ACID MVCC+ database. On small to moderate hardware MySQL and PostgreSQL will smoke any commercial DB except maybe SQL Server since it doesn't do MVCC.
It's all a trade off. To say one is better than another means you're not factoring in the application and needs of the user. It pains me to say so, but sometimes I have to tell the customer . . . "Your best bet is SQL Server". :) However, if I'm staying more than a few months I'd much rather see them use PostgreSQL in most situations, and even MySQL in a few.