Slashdot Mirror
PostgreSQL 7.4 Released
Christopher Kings-Lynne writes "PostgreSQL 7.4 has just been released. The list of new features is impressive and includes greatly improved OLAP performance among many other speed improvements."
← Back to Stories (view on slashdot.org)
If you ask me, I'm glad that people opine and wage war when it comes to PostgreSQL vs. MySQL. MySQL has done for PostgreSQL what windows has done for Linux: make it want to thrive, compete and prosper.
This is also why Microsoft WANTS there to be an enemy: they need someone to compete against to continue improving their product (which they do, even if we hate to admit it).
If you don't believe me, ask Dubya.
There are two kinds of people in the world: Those with good memory.
Are they having a hard time convincing you to try mySQL, too? ;-)
evil adrian
My Sequel. Simple.
"Sequel" is a Microsoftism. The rest of the world calls it Ess Que Ell.
For some applications with a chance of growth I've had two issues with Postgresql. One is that despite the fact that they have talked about being an "enterprise level" database for ages, we found that in any kind of swift moving transaction enviroment we had to VACUUM pretty regularly. How they expected folks to leave pgsql running over extended periods of time (months -> years) is beyond me. Looks like they may have solved it. It will be interesting to see if the systems can take a pounding and stay up 24/7 for a while without slowing to a crawl.
The other issue has been replication. With mysql this has saved our bacon more then once. Nead to do intensive analysis on live data and don't want to disturb active system? Set up a nice slave and query away.
Want basic fault tolerance? Set up a slave, you have a live mirror of the data.
Have lots of queries coming in (load balance the reads at least).
PostgreSQL now has some type of replication available from PostgreSQL Inc, but it looked to me like somewhat of a hodge podge of perl, triggers and who knows what else.
I think I'll try it out, and if I can get the same replication speed as I do with a mysql array I'd switch over, but first glance it didn't look like I would. Anyone compared the replication performance yet (and ease of setup, I was very impressed with mysql in this regard).
I work with both of them, so I can compare both. Personally, I see many cases, especially when the data model is complicated enough, when PostgreSQL is faster than MySQL. But for that I am spending some extra efforts, because many OSS projects are ported to work with one DBMS, not with both.
I love PostgreSQL and it's functionality but unfortunately there are still many developers of other open source projects who heard about MySQL and did not do any research for existing alternatives and thus made his project based on MySQL.
And, again unfortunately, while PostgreSQL is very close to SQL standard, but MySQL is not that close, so you cannot just substitute the database library - you have to re-write (and thus re-test) all SQL code of the project. So, that's why I still have to use MySQL.
With all my respect to great technical quality of PostgreSQL software, I think PostgreSQL team doesn't do a great job to make PostgreSQL being popular. The athmosphere in PostgreSQL community reminds me the one of BSD (read: very unfriendly).
Less is more !
And it is very, very nice. If you have people resistant to using pgsql (which I like a lot personally) pgAdmin III will give them all the GUI stuff they are used to from programs like SQL Server Enterprise Manager.
The postgreSQL community is extremely helpful, key developers are very active in helping out users and addressing issues rapidly. It is a project that just exemplifies what is good about open source.
I am compiling 7.4 on my development server right now in preparation for moving our production server soon. I guess maybe I sound like a fan boy but as a database administrator I just can't over emphasize my joy at getting to work with such an excellent product.
It's hard to believe that's how Micronians are made. Why don't we see it right now by having you both kiss one another?
The Monks said it all (about Notes): Nice Legs, Shame About Her Face.
This is not the sig line you are looking for... -- Old Jedi Sig Line Trick
Huh?
ERServer was released open source months ago. Check out GBorg for more information.
And why do YOU need raw disk access? The PostgreSQL developers belive (and rightly I think) that the operating system can do the caching better than they can. Why re-write the wheel? Operating systems have came a long way in the last 10 or 12 years. Days of slow access to the disk are long gone.
BWP
They are tools for different jobs:
MySQL is intended for systems where the data is uploaded, and thereafter never changes significantly - eg static data accessed via the web.
PostgreSQL is intended for things like payroll systems where some values persist for years, while others change daily.
Without triggers, you cannot expect to maintain data integrity with online data input and a wide range of input methods. ie any system with an expected live lifetime exceeding a few months
Sent from my ASR33 using ASCII
Untrue? Since when has MySQL had stored procedures? Do you even know what stored procedures are? Do you run 10 database queries on every web page?
How about subqueries? Do you run a query and then run queries on the results in the application?
Simple selects might be slightly faster in mysql, but very few applications do a single simple select at a time.
he is an idiot who doesn't understand "different tools for different tasks"
So a guy I work with was bitching about his Geo Metro the other day - he was complaining (for the umpteenth time) that it takes too long to drive the 300 miles to work each day.
So I say to him (again for the umpteenth time) "Dude, you work across the street from an airstrip, and your driveway is large enough to function as a landing field - get a plane."
So the next day, he tells me that he decided to take my advice and try a plane - a small single-prop Cessna.. then he says that it sucked! It was slower than his Metro!
"How can that be?" I asked.
"Well, every time I got the damn thing over 40, the wheels came off the ground!" he says.
"So? It's a plane, not a car - that's what's supposed to happen." I said.
"That sucks!" He says, "I don't know how to fly a plane! I'm sticking with my Metro - it's faster than that Cessna!"
Then I tell him that the Metro is only faster if you don't know how to fly a plane.
And then he went and muttered something about "different tools for different tasks" - completely missing the point that he's ignoring the correct tool because he's unwilling to learn how to use it.
There's a moral in there - I'll let you figure out how it's applicable to this conversation.
I'm thinking I should give it a while. I hope it's better than MySQL, because, in my opinion, MySQL is overrated.
I've recently started a project using MySQL because we want to get away from the ridiculously overpriced licensing that MS makes you get. I'm not trying to be a troll or anything, but I'm trying to give a realistic viewpoint by someone who's used to MS crap, but really wants to switch over to open source.
I love Open Source and I definintely try to keep an open mind about it (hey, whatever gets the job done at are more efficient and cost-effective manner is good stuff) and am by no means a Windows/Linux zealot.
Take a look at MySQL's current state. Way behind on the times... for example: it *still* doesn't have stored procedures. Do you realize how annoying it is hardcoding SQL statements? There's complete lack of subquerying, which really makes it a pain to do certain calculations often requiring additional queries, which is extremely inefficient (although I do understand that it's currently in alpha).
Things like this.. make me think twice. If these useful features haven't even been implemented yet, then how can I (someone who's used to using MS crap) trust it?
I'm gonna give PostgreSQL a try and hopefull it has more functionality (and stability) than MySQL!
We have secretly replaced these Slashdot mods' sense of humor with a rusty nail. Let's see if they notice!!
Trading stability for speed is stupid.
Period. End of story. The job of a RDBMS is not "be fast".
Maybe then, they need to stop claiming they're building a relational database management system because they're obviously not and anyone who thinks they are is addled in the head.
If the application layer has to handle data integrity, the system behind it isn't relational and it's arguably not even doing the job of a DMBS. More like a convenient indexing tool.
MySQL makes a fine database management system where it doesn't matter if your data gets mangled and all you want to do is fast, simple SELECTs, but what irritates the "zealots" like me is that MySQL folks will actually sit and argue that MySQL is even remotely close to a RDBMS. pgsql and their ilk aren't truly relational either.. but they're a heck of a lot closer.
Alito: A vote for Alito is a punch in the eye to put that bitch back in her place!
We are in the midst of moving our databases away from Oracle. There were three contenders: MySQL, Postgres, and Matisse (OODBMS).
Speedwise, PosgreSQL trails the pack by a fair bit. Sometimes it would be comparible to Oracle, and other times it wouldn't be without a fair bit of tuning. Outer-joins, for example; the optimizer can't seem to make heads or tails of it.
I spent two years lurking on the Postgres lists, and when doing performance testing, was asking for help tuning queries and the database in general; this isn't a statement made based on, "I tried it once, and it didn't work."
The guys on the list (especially Tom Lane) were very helpful and polite, but I just couldn't get reasonable performance out of the database without doing some serious SQL-rewriting (our CTO thinks that relational databases require too much tweaking already; putting optimizer hints into the queries is just too much).
Overall, the database is great - great feature set, great developers, and a good support community, but the optimizer is not efficient enough (search for the word optimizer in the PostgreSQL lists, and you'll find hundreds of posts where the optimizer is doing a sequential scan and ignoring indexes when it should be using those indexes).
MySQL (4.0.16, using InnoDB tables) has foreign keys, transactions, etc. I haven't been able to crash it yet (I miswrote a query on purpose, and let it run over 2 days at 99% CPU, and the machine stayed up, and is still up a week later).
MySQL doesn't have triggers or stored procs, but as a DBA and senior developer, I can honestly say that's a good thing.
- if you modify a table that a trigger or stored proc uses, chances are the trigger and stored procedure are invalidated quietly behind the scenese - the database doesn't tell you until you call the stored procedure or execute a statement that causes the trigger to be executed.
- debugging a stored procedure or trigger is not easy.
- people tend to forget about triggers and stored procedures; they're hidden logic that can cause no end of problems.
- triggers and stored procedures are (in most cases) database-dependant; they are a huge hinderance when moving to another database. We have 12,000 lines of Oracle stored procedures. I dislike them.
- the database is for data storage. It's not for application develoment. Keep the business logic in the application, and the data-storage logic in the database. Oracle is trying to sell their RDMS as a development tool to justify the price. Don't believe the hype.
PostgreSQL is trying to position themselves as an Oracle replacement, and thus have a similar feature set. PostgreSQL is also very good at very large databases (probably even more so than MySQL, at least until InnoDB gets multiple tablespaces in the next release).
Databases with simple queries where results are not needed instantly would do well with PostgreSQL.
Errm, have you seen what's involved in actually _using_ this replication system?
Yes I have, and it's not all that hard to set up. Not a simple drool and click interface, but no harder than setting up the ftsearch or a few other projects I've put online
And actually, I'd rather have the database decide what gets cached and what doesn't.
Really? Even if it makes the wrong decision? What if the decisions it made would be exactly the same, is it still worth the 100s of man hours to create such a cache manager and maintain it?
You present no metrics for WHY the database should decide what stay in cache, yet you assume it would make a better decision. There are tons of things still to be done in Postgresql, (like the win32 port, Point in time recovery, 2 phase commit, and replication) to piss away time on a project of dubious returns like this.
--- It is not the things we do which we regret the most, but the things which we don't do.