Slashdot Mirror
PostgreSQL 8.0 Released
Christopher Cashell writes "The PostgreSQL project has released version 8.0 of their well known Object-Relational Database. New features include: Win32 Native Server, Savepoints, Point-In-Time Recovery, Tablespaces, and lots more. Downloads are available via bittorrent for Unix/Linux, and the much anticipated Win32 version, or via ftp (use a mirror!)." (Here's the official announcement.)
Even more important than being a replacement for MySQL, in many situations it can be a replacement for MSSQL!
What happened to the big news about the Java stored prodcedures? Wasn't there some news not to long ago about adding support for this in Postgres? To me that would been a more welcome feature than the rest of the stuff.
I hate it when MySQL fanboys jump into threads like this only to show their ignorance of relational algebra and predicate calculus saying that no one should ever bother with PostgreSQL and ACID-compliance, because MySQL is somehow a "better tool for the job" in the "real world". We already have comments saying that, so people, please read this first: [1] [2] [3] [4] [5] [6] [7] before you post yet another misleading plug for your favorite toy. Thank you. A real relational database is more than just a data store with SQL frontend.
Good to see they're back in the race, coming up with something serious - and Thanks, Oracle! for being a tough competitor providing a solid standard to keep up with. PostgreSQL is, in my opinion, the most presentable of not-too-much-$ database solutions, I sure like to present clients with a new version of P rather than the crummy image of MySQL (by no means an inferior product but not profiled in the same, serious way). Ah and let's see how it runs on Mac OS/X - Darwin, too. Maybe my little 12" will become all the more a p0w4hful tool because of it - and it had better, I haven't paid the thing off, yet! ...
* Signal 15... "Ceterum censeo Microsoftem esse delendam." Cheers cq. BRgds: DrS aka UNIXmafia@ribeco.net
... and it would really really rock!
Said that, PostgreSQL is a really great thing, and being FOSS, I could of course always go ahead and add the named features... .)
I would consider the PostgreSQL gotchas to be of an entirely different category as the MySQL gotchas.
In PostgreSQL the gotchas are all about performance. And while it may be bad that the database crawls if I didn't schedule a job with vacuum and analyze, that does not have any long term effects. I just run the maintenance tasks manually, add them to a cronjob and I am good to go.
In MySQL however, the gotchas are mostly about data integrity. And that means that they can be disasterous because they can lead to dataloss. Unless you can explain to me how to get back whatever was silently truncated by MySQL if I discover the problems a few days later.
I do very much prefer PostgreSQLs focus on data integrity. But of course I actually read the manual so I won't be bitten by them in either database.
In my last project I was forced to use MySQL due to hosting issues. I still believe that MySQL is the Access of the OSS dtabases (in a non-GUI way).
I have several tables with over 3 million rows, and most aggregates return immediately (or nearly immediately). count(*) is the only dog since it reads every row to get the count, but it's acceptable since I rarely count all rows in the table. I've often wondered why the developers couldn't keep an internal count of all active rows, so count(*) would return immediately, but I'm sure they have their reasons.
You've got to be joking about PostgreSQL having a weak optimizer. If it's weak, only the computer can tell.
Your Wiki link spent most of its space praising PostgreSQL for its advanced features, while your intent is clearly to denigrate it. If that represents PosgreSQL's worst facets, then I am very, very happy.
I wrote a PHP program that tracks my gf's and I's finances
Be very careful with PHP there. Be sure you're using transactions to make sure your page finishes loading, or an error on the page might make half your database statements execute before PHP says "oh wait, this is wrong" and dies. There are other cases too... if your browser drops the connection theres a php configuration flag you have to set to make sure the script completely executes instead of terminating immediately, and other gotchas inherent in this.
So to recap: "pgsql has transactions, use them."
My favorite gotcha not mentioned is how MySQL's own system tables are all MyISAM. That's right, they're not transaction-safe, so if you roll your own admin scripts, be very very very careful.
Seems to me Hibernate is the closest there is in that field. IIRC its lead is now working on EJB3 specs. It's a Jboss project, and I've used it with Tomcat without problems.
Information: "I want to be anthropomorphized"
Have you used PostgreSQL recently?
Performance hasn't been an issue since at least version 7.
*sigh* back to work...
If only a simple and integrated replication mechanism would appear, I would consider switching back to PostgreSQL from MySQL.
I miss PostgreSQL, but too many things are made easier by replication.
Performance is still an issue when you don't read the manual and never perform maintenance on your database. No matter how good the planner is, if it doesn't have acurate statistics because nobody ever runs ANAYZE your database will crawl. No matter which version you use, if you never VACUUM dead row versions will accumulate and eventually kill your performance.
I use PostgreSQL on a daily basis and when I change a database schema I will make sure that I run a VACUUM ANALYZE after committing the changes. But many of the people that we host don't bother to read the manual and don't do this. Usually this is no big deal because it gets picked up by the scheduled jobs. But every now and then somebody calls in a panic because their website is slow. And it always turns out to be major schema changes throwing the planner off. A quick VACUUM ANALYZE gets the performance up again and the customer is happy and has (hopefully) learned a valuable lesson.
This is a real gotcha in PostgreSQL. It has made a few of our customers' websites crawl for a few hours on occasion. But it has never caused dataloss.
I'd be careful with statements like this. Postgres competes well with Oracle for a variety of applications. However, Oracle still has some VLDB and high availability features that aren't yet available for Postgres. Also, for a lot of folks, what matters isn't the database, but stuff like the availability of financial packages. There is also a lot of inertia with Oracle-that could be handled by creating libraries that give Postgres a higher degree of API and language compatibility with Oracle. I'm rooting for Postgres-but Postgres has a ways to go before Oracle is truly dead.
You're telling me that MySQL locks the entire table when I insert a row? You must be joking - that would bring a database to it's knees.
Why do you think MySQL performs so poorly with large number of concurrent users?
LedgerSMB: Open source Accounting/ERP
I think DB2 and other commercial databases do it this way anyway. They just encapsulate all the steps in an the ALTER table function.
One thing to add is that you might have to rebuild any indices that use that column though. That's bitten us a few times using third party tools.
"Fighting the underpants gnomes since 1998!" "Bruce Schneier knows the state of schroedinger's cat"