What Is New In PostgreSQL 9.0 213
Jamie noted a blog that says "PostgreSQL 9.0 beta 2 just got released this week. We may see another beta before 9.0 is finally released, but it looks like PostgreSQL 9.0 will be here probably sometime this month. Robert Treat has a great slide presentation showcasing all the new features."
Built-in replication (Score:5, Interesting)
A better summary of the changes is here [postgresql.org].
After years of resisting, one of the more significant changes is the inclusion of WAL shipping-based replication into postgresql core, and the ability to do read-only queries on the standby systems. This will hopefully go a long way towards appeasing mysql users used to the "easy" replication that mysql provides.
Color me skeptical. (Score:4, Interesting)
Do you have an actual example? I simply don't see how removing a column from a select clause would make a query slower, unless you're talking about uses of aggregate functions, and even there I'm having a hard time seeing how a removal could make things worse.
The thing that determines how much work the database has to do in order to produce the results is the FROM, the WHERE and the GROUP BY, because those are the ones that determine what's going to be accessed, joined, sorted and how. The SELECT (except for the use of aggregate functions) primarily just decides what information to present from the join results and how to present it.
Re:Built-in replication (Score:5, Interesting)
And streaming replication. It makes it a lot easier to have a backup server that is up to date. It makes me happy so I can do partial restores without a lot of fuss.
Now, if only the enterprise apps could find out to reconnect to the database and continue where they left off without crashing and trashing.
I'd say something, but someone will freak out (Score:2, Interesting)
I don't understand. What is the advantage of PostgreSQL verses MySQL or a seperate HTTP server?
Forget it. I know someone is going to freak out and mod me troll. I do not intend to cause harm.
Re:Still waiting (Score:3, Interesting)
and now there's Postgres-XC, which looks very promising
Re:Join removal is cool (Score:2, Interesting)
What you just stated sounds all well and good...but its not very informed. Or maybe just informed from 10 years ago.
In general a database is pretty much as good as its DBA. That said, your statement about Postgre being vastly superior is strictly a contextual one, and even then would be a trade-off at best case.
For the DBMS corner cases that MySQL doesn't do, there are some incredibly important things that Postgre doesn't do.
I see in the updates that Postgre is finally doing Streaming Replication? Just now? Before this, you had to rely on 3rd party "hacks".
Meanwhile, MySQL has done instant replication and failover for quite some time.
More importantly, MySQL has done Master/Master replication for years now, natively, with relative ease. I have been doing Live Hitless upgrades to sites for years now, to infrastructures built on MySQL. Sites doing 5-10k questions per/sec. on minimal hardware(relatively). No Down Time. That is huge when it comes to "stability" of a website or web application when everything is DB dependent.
Don't get me wrong, I like Postgre. I have for years. But don't go around talking the old line that MySQL is an severely incomplete DB for the ignorant. It has matured over the years into one of the most capable, feature complete, stable, and useful databases available.
dimes
Comment removed (Score:3, Interesting)
Re:other then features... (Score:3, Interesting)
Above and beyond SQL-92/SQL-99, PostgreSQL does a good job of implementing the non-optional parts of SQL:2003 and SQL:2008 as well, and in that regard are competitive with or better than the commercial alternatives.
PL/SQL is probably unlikely to ever be available in the Open Source PostgreSQL product, but it is a feature of EnterpriseDB, which is a PostgreSQL superset.
INSERT..ON DUPLICATE KEY UPDATE is IIRC similar to the new SQL:2003 MERGE statement, which is on the TODO list for PostgreSQL.
CLUSTER is a subset of Oracle's index-organized tables / SQL Server's clustered index features.
One of the truly innovative features that is arriving is exclusion constraints. If you've ever had to implement a scheduling system that deals with concurrent updates, you'll recognize that PostgreSQL has an absolutely killer feature that makes it trivial to solve the concurrent range-excluded searched update problem without messy application code. This feature is pure gold.
Designing a performance-intensive application that is portable across multiple databases is a frustrating, difficult task. Starting with ANSI/ISO syntax is indeed a great way to base your design, but the devil is truly in the details. ORMs can hurt as much as they help.