PostgreSQL 8.3 Released 286
jadavis writes "The release of the long-awaited PostgreSQL version 8.3 has been announced. The new feature list includes HOT, which dramatically improves performance for databases with high update activity; asynchronous commit; built-in full text search; large database features such as synchronized scans and reduced storage overhead; built-in SQL/XML support; spread checkpoints; and many more (too many major new features to list here). See the release notes for full details."
Re:Cross Database Joins?? (Score:1, Insightful)
asynchronous committ (Score:5, Insightful)
Re:Cross Database Joins?? (Score:5, Insightful)
long live postgres (Score:4, Insightful)
I can only assume that MySQL keeps it's large market share because it has commercial backing and therefore good support. I'm sure there are plenty of products taht don't require that level of support though.
Time for a cross-DB comparison (Score:5, Insightful)
There are so many Open Source databases (MySQL, MaxDB the last GPL version, Firebird, Postgresql, Ingres Community Edition, hsqldb and H2) that it is hard to know which ones implement what, which ones are useful for what, or which ones are optimal for what. Simple benchmarks (a) rarely are, and (b) usually want to promote one specific product over another. There are standardized tests, for a small fortune and by a relatively closed group who probably don't have a fraction of the range of experiences of databases in the real world, so cannot possibly be trusted to authenticate a standard or measure that could be used to compare databases.
We could really do with some serious side-by-side evaluations of these database engines, or at least decide what such evaluations would need to be to be actually useful. (Hey, maybe CmdrTaco can add a comparison section, get it sponsored by Which? or some other consumer guide, and have some of us run evaluations. It'd have to be done well to not be flamebait, which I think might rule me out, but if it could be done, it would be hellishly useful.)
Re:asynchronous committ (Score:3, Insightful)
It's not a feature you will use in your web or c/s app, but it has it's uses, and it's good to have it there.
Re:asynchronous committ (Score:3, Insightful)
Re:New HOT, faster Postgres (Score:5, Insightful)
Of course, if you actually care about data integrity and database features, there's not contest at all. But the performance gap is now non-existent, if not completely reversed.
Re:Cross Database Joins?? (Score:5, Insightful)
That feels wrong somehow; if your (logical) databases are so distinct that you can't plan to co-locate them in the same (Postgres) database, does it make sense to have such tight coupling on the query side? Now you have to synchronize the data between them, and you can't move them off the same machine, so what's the point of keeping those databases separate? It also seems like client code should never have to know where different databases are physically located.
I don't agree that this is the "simple solution", it's a horrible hack on the part of the database engine (I don't actually know if anyone apart from Oracle does this) with unpredictable performance results - looks more like the "lazy solution".
I don't know, just seems like such a thing breaks the database/application "contract".
Besides, shouldn't your ORM layer abstract such minutiae away pretty easily?
Re:asynchronous committ (Score:3, Insightful)
Asynch writes are useful for keeping history on data that may be used to recreate or replay a period of time of data flow that is more dependant upon trending and rate than actual values. Say you have an automated trading system and you're working on various reaction algorithms based on market events. Recording a real-time stream of market data for playback during system testing is a perfect use for asynch commits. You want a replayable record of market data flow but the order it came in and even missing some records isn't as important as the data set as a whole.
Re:New HOT, faster Postgres (Score:5, Insightful)
And that's only with MyISAM (in which case, why bother with a database server? SQLite is probably enough for your needs).
Re:How quickly they turn on you .. (Score:4, Insightful)
Would it make a difference to you if they bumped up the version number to 9?
Re:long live postgres (Score:3, Insightful)
Re:long live postgres (Score:2, Insightful)
Re:Will it be used? (Score:3, Insightful)
Re:whuh? (Score:3, Insightful)
I think the disconnect is that PostgreSQL has a different definition of schema [postgresql.org] than you are using.
Re:Will it be used? (Score:1, Insightful)
Your the first person in this thread to say that Postgre is faster than MySQL in raw speed.
Everything I have read confirms that MySQL is faster but has less features and is less 'correct'.
PostgreSQL is well known to be far, far, faster and scalable than MySQL save only for MySQL's sweet spot. MySQL's sweet spot is, simple, read-only, repeated queries where cached results can be applied, or where 95+% is all inserts with limited read/delete activity. Writes with concurrent reads kill MySQL because of locking. And even with that qualifier, MySQL still has significant problems scaling (that means lots of queries at the same point in time. In many benchmarks, MySQL is unable to even complete scalability tests, using crashing or locking up before completion). Simply put, by far and away, all but the most simple of applications fall outside of MySQL's sweet spot...and even then, those that do fall within tend to grow outside of it over time.
Let me give you an example using made up numbers so you can understand what I'm talking about. If you don't believe, feel free to find, or better yet run, your own benchmarks. One word of warning, MySQL has a very long history of lying and making up benchmark results, so please kindly ignore theirs. No one but MySQL seems to be able to reproduce their results...and on the rare occasion they can, the benchmark is otherwise tainted with biased hardware and/or configurations (apples to oranges comparison).
Based on this example, I belive you'll understand why so many MySQL people falsely believe MySQL is fast. Because bluntly, it is to the untrained eye; which is by in large, the bulk of MySQL users.
MySQL PostgreSQL
1 10 100 1000 1 10 100 1000 (concurrent, mixed, simple queries)
3ms 8ms 20ms crash 4ms 7ms 12ms 20ms
MySQL PostgreSQL
1 10 100 1000 1 10 100 1000 (concurrent, mixed, complex queries)
9ms 19ms 30ms crash 10ms 16ms 24ms 40ms
Notice for simple, single queries, which is what most MySQL developers do, MySQL appears to be faster. Well, not just appears to be, it is! But once you start adding additional load, MySQL typically falls far to the back of the pack of other RDBMS; which includes both alternate open source databases and commercial offerings. The problem is, by far, most MySQL developers are clueless as to what scalability means, what locking does to performance, why ACID is good, so on and so on.
Now then, add in the fact that you can write stored procedures in any of a handful of languages in PostgreSQL, and MySQL and you soon realize MySQL is the Tonka Toy of the RDDMS world. Frankly, almost any other DB will do better than MySQL, be it features or performance, save only for its sweet spot. And frankly, where MySQL excels, several other, much faster options are typically available, which does not require the overhead of a RDMS.
Long story short, you'll typically find those that willingly pick MySQL for their project are completely unqualified to be in a position to be asked to make such a pick. *Almost* every time, there exists a superior solution, be it PostgreSQL or some other data storage solution. Generally speaking, MySQL is picked because it's popular, not because it's good. And if you don't believe me, next I'm sure you'll be arguing VHS won because of superior quality of Beta.
Re:PostegreSQL 8.3? (Score:3, Insightful)
A TCP connection is uniquely identified by *all of* the source IP address and port, and the destination IP and port. There can be many connections to a server on a particular port, distinguished by the client address and port number.
Of course to get more than 2^16 connections you would need more than one client machine.
Re:Nice. (Score:3, Insightful)
You have made two very serious flaws with your thinking about how and why you chose MySQL. In general it's rampant with PHB thinking.
There is the obvious discussion you didn't have when you decided MySQL was better for your company. Why would you take something as important as your company database and leave it to a vendor to support? You have no in-house knowledge of your database. You have no back-up in the event that vendor gets into a contract dispute with you. And every time you need their support on anything you have to go through this slow interface of vendor management rather than just leaning over to the company employee named Roy who lives and breathes MySQL or PostgreSQL and say, "Hey Roy! Somethings wrong with the database. I need you to fix it right now. I'll get you a pizza for lunch."
The other error in your thinking is more elusive but this reminds me of a conversation I had with a room full of people regarding the expansion of Java at the potential cost of Perl developers.
"I can get a whole boatload of Java developers from overseas with a phone call and 72 hours. It's very hard to find 20 or 30 Perl developers for a project."
Nobody in that room had ever worked on a project requiring more than 5 developers. And they had worked on some largest Perl projects out there.
Subsequently I have found a lot of really bad Java developers.
I can have a similar discussion with MCSE in place of "Java developers".
The flaw is that you assume popular support equates itself to good support. I think the exact opposite is more likely to be true. If someone is in need of a quick job and quick bucks, they will take the fastest and lowest entry barrier solution. First comes Am-Way. But with a week of sitting in classes for each they can quickly become a Java certified developer, MySQL DBA, or dot-NET developers. All this in three weeks time and with the credentials to prove it. Are they any good at what they do? Not likely.
The contrary group of people are those who use PostgreSQL over MySQL or SQL Server, Linux over Windows, Perl/Python/Ruby over dot-NET or Java. They stay here and learn this less popular software because they enjoy it and find it interesting. It's generally not a decision based purely on money. It could be argued that Ruby isn't in the same camp as Perl & Python because it's having something of a feeding frenzy in the PHB camp. But that's Rails, not Ruby, and they are different.
It is fair odds that if I put out a couple inquiries I could find PostgreSQL support in Detroit, MI (not a software haven) within 72 hours and based on it's lack of a Marketing and PR campaign the person who shows up at the door will know more about PostgreSQL and how to get it working smoothly than the MySQL counterpart who shows up at my door. And I will only need one of them as opposed to hiring 2 or 3.
Re:Why PostgreSQL doesn't have more of the market (Score:3, Insightful)
Forget about the Wiki part. "Shared" here means that many clients are simultaneously reading from and writing to the same store. Sites like Slashdot and Wikipedia are darn near read-only in that sense, because a comment or article is typically viewed many thousands of times more often than it is written or edited.
Contrast with something like a point of sale system where each time a clerk scans in a product, a unit is removed from the inventory database and the accounting system gets updated with the new revenue. Multiplied by a few thousand terminals, that is a large, shared data bank.