Slashdot Mirror
PostgreSQL 8.3 Released
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."
I'm confused. Do you mean you should avoid cross-database joins during the design phase? If so, this isn't always possible. Often databases are created in a vacuum and only later does one need to utilize multiples in a query.
this was a new feature for Oracle with 10g R2 also - and as a DBA I can only shake my head and ask "why?" Why would you want to drop the durability part of ACID? Why would you risk losing data for speed? There are so many ways to tune things and speed things up without taking such drastic measures. I know I'd fight tooth & nail before I'd turn this on in anything I managed. I just hate to think that someone with less understanding is going to think of it as a 'go-faster' button and then blame postgres when they lose something important.
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?
There are several ways to do cross-database JOINs in Postgres including dblink, and even to other DBMSs via dblink-tds and DBI-Link, but try schemas first, as another poster mentioned.
What part of "A well regulated militia" do you not understand?
As far as databases go I don't think it gets much better than Postgres and I reckon over the years I've tried most popular databases. What I really don't understand though is why Postgres doesn't own more of the database market. Sure it was a bit slower than MySQL a few years ago but the benifits that you reaped for that slightly slower speed far outweighed the cost. The difference know is, I would say, much small and less significant.
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.
I used to have a better sig but it broke.
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.)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Yeah, if only for those darn inconvenient facts demonstrating that PostgreSQL is faster than MySQL, particularly under load. Note that the benchmark was PostgreSQL 8.2. Now note that 8.3 is up to twice as fast as 8.2. I think the polarity on your order of magnitude performance difference should be reversed.
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.
Higher Logics: where programming meets science.
Often databases are created in a vacuum and only later does one need to utilize multiples in a query.
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?
sic transit gloria mundi
Oh give it a fucking rest. MySQL is 10-15% faster on simple queries, with few threads, on a single disk.
And that's only with MyISAM (in which case, why bother with a database server? SQLite is probably enough for your needs).
sic transit gloria mundi
Going from 8.2 to 8.3 in postgresql is not a 'minor' release. It's quite a major step with a lot of new features.
Would it make a difference to you if they bumped up the version number to 9?
And even more instances where they are needed, but not known/understood by a MySQL user.
I think the disconnect is that PostgreSQL has a different definition of schema than you are using.
Dewey, what part of this looks like authorities should be involved?
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.
There are 2^16 port numbers, but there are no theoretical limits on the number of connections incoming to a single port.
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.
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.
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.
Dewey, what part of this looks like authorities should be involved?