Slashdot Mirror
PostgreSQL 8.0 Enters Beta
gavinroy writes "As announced in pgsql-announce, PostgreSQL 8.0 Beta is now available. New features include native win32 support, Point in Time Recovery, Tablespaces, and much more! here is the beta history if you want more information."
it is the most advanced Open Source database there is. If anything pissed you off with MySQL chances are Postgresql will have a solution for you.
The move to have a Win32 Native executable was to allow PostgreSQL to to compete with MySQL.
Synchronous replication is the only feature that will allow PostgreSQL to compete with Oracle. Mission critical backends need systems that stay entirely in-sync and if any one of the nodes fail, the system can fail-over to one of the other db's.
Master-slave just isn't sufficient.
You cannot overlook the speed aspect as well. For many, many databases, the special features of foreign keys, stored procedures, etc. are not required. I have worked extensively with Oracle databases in the past, so I am well aware of the advantanges of these advanced features. However, in my current company, there has been no need. Most of our databases, while large, consist of a very small number of tables. The vast majority of our searches are performed on a single table, and these searches are completely optimized for speed. Stored procedures will not help in these scenarios, and foreign keys are not needed. I imagine there are a lot of web sites and applications that have the same characteristics.
I will not deny that the Windows support is huge, but it is not the only factor in MySQL's court. Speed is a huge issue, especially in the database world.
I believe in de-evolution. God made the world perfect, man fell, and its been going downhill ever since!
Just in case... posting comments about the color scheme, while they make you feel better, don't affect the /. editors much. If you don't like the color scheme, the best is to email the editors and let them know. They pay attention to email much more than comments (which they may not even read).
In 8 years i've never lost data from an Oracle database from a software problem. I've seen data get lost, corrupted for a number of reasons including incompetent DBA's and their managers. (Off topic but once I was called into a major telephone company because they had some corrupted blocks from a hardware issue. I asked them how long did they keep their backups, 3 months they replied. Ok, how long have you known about this problem, 5 months. Hrmm... 3 - 5 = -2. You can fill in the rest of the story..)
I haven't used postgreSQL in a production environment long enough to know how stable it is. The reason companies choose commercial vendors for their DB's are two fold:
1) Track record. They know if they pick Oracle or DB2 they are getting a solid,proven database system. And there is an abundance (if not expensive) of knowledge out there. Their support is bar none and for the most part I have been extremely satisfied.
2) Managemnt loves to save money. Who wouldn't want to be able to say they saved the company millions of dollars by going to a 'free' or inexpensive (if you pay for support) rdbms like postgresql or mysql. One reason, blame. Opensource still has the stigma attached to it that no one is accountable for bugs. If a critical revenue generating db goes down because of a bug a manager needs to be able to point their finger. Until this stigma goes away we won't see alot of opensource adoption in the DB market. Whether this is right or wrong doesn't matter, people don't like change and opensource is a huge change for alot of managers.
"Thanks to the remote control I have the attention span of a gerbil."
If they use an RDBMS they have the code to, yes, they have the option of bringing an RDBMS on staff and doing custom improvements and fixes. However, they also have the option to go hire some other company to make the fixes and improvements they need.
The user of PostgreSQL has a whole market of developers to choose from. The user of Oracle has only one choice, and that company is known for taking a monopolist*'s rents from its customers.
PostgreSQL has always been ahead of MySQL in terms of everything but speed.
That blanket statement is simply not true. Most people think that a single user with a single query is a measure of speed. For most applications, it is not. And bluntly, this is exactly where MySQL's performance advantage starts and stops. MySQL simply does not scale nearly as well as just about any other RDBMS you'll find, including PostgreSQL.
Granted, there are still some corner cases where I'm sure MySQL is faster, especially when you're not using ACID compliant tables, but make no bones about it, PostgreSQL is much faster than most people realize and MySQL is much, much slower than is commonly believed.
Maybe it is because MySQL treats TEXT fields as binary since it has no Unicode support (at least, the current stable, non beta release).
But then again... a man's bug is another man's feature.
PostgreSQL adheres to the standards more than MySQL, so you're using a language with broader industry adoption if you use PostgreSQL. Especially from someone who says, "If X then we'll use Oracle", you ought to know that PostgreSQL would make migration to/from Oracle easier.
To the second question: Nobody in the open source world.
Microsoft's on the way to doing it, and there was a small project that existed for a few months that allowed GNOME to access a database as a file system (It was very nasty; involved a kernel patch (a CORBA orb) that nobody was too happy about, so the project never took off.)
I've thought about the problem a few times. It requires the kernel pass information back to user space, unless the database was actually incorporated into kernel space (and that won't blow over well for a number of reasons). Passing the data back to user space requires a messaging system. The problem is, there are very few messaging systems out there designed specifically for kernelspace-userspace communication. CORBA was one developers answer; my answer would to be to ground up a protocol (because I feel that a network messaging solution, i.e. TCP/IP, can't be secured well enough in the long run).
Lastly, a daemon needs to exist to listen to the calls from the kernel and interpret them into SQL. This could be built into the kernel itself, but once again you have to question the security of the kernel building an SQL query that would go directly to the database server. Also, one of the better parts about this daemon would be metadata extraction; since the daemon is virtually transparent to both the user and the database server, the metadata can be completely ripped from the data and stored in a seperate table to allow for much faster, more optimised searches. EXIF Tags can be copied from JPEGs, ID3 tags copied from MP3s, etc.
Ideally, the daemon would be pluggable, allowing for anyone's metadata extension to be added after compiliation, but I believe that it's important to have a functional system before having a featureful system.
If you'd like to talk more about it, I'm really open to the idea of finally having an SQL-based file system. A relational database file system is the future; if we get there before Windows, we can add yet another example of the speed of open source development.
"Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
I can agree with you, if you want to get a lousy job done fast, then MySQL is exactly that type of DBMS you pick. I mean, if you have few, mostly not conflicting, updates and mostly just need fast query, you will be fine.
On the other hand, if you want a full scale, acid compliant, transaction oriented DBMS, and your priority is many updates and fewer queries, and you have accent on quality of your data, you will pick PostgresSQL.
Many websites fall into the first category. But for example large scale email system would be much better off with postgress. Also, you can have a read-only query database on MySQL and read/write database on PostgresSQL if you want to get the best of both worlds.
If programs would be read like poetry, most programmers would be Vogons.
It's like deja vu all over again.
Mysql is still able to read and write ancient databases (the ISAM format was defined in 1986 and can still be read).
Actually, it's not the format of the data store so much as changes to the system catalog, which are put in place during initdb.
There has been a project for upgrading in place, but it just hasn't had enough man power thrown at it to be a viable solution.
Maybe it's time for you to volunteer?
--- It is not the things we do which we regret the most, but the things which we don't do.
If your main concern is speed you should not be using a relational database. If your main concern is data integrity, you should not be using MySQL.
Engineering and the Ultimate
Dude, with "kill -9" it will not be long until you corrupt PostgreSQL, MySQL, etc. too.