The sonic cruiser was killed by simple investor caution combined with lack of information, not economics. And Boeing's new proposal has no significant selling point over the alternatives offered by Airbus.
That's interesting. At the time, it was widely offered that it fell through because the carriers were not going to buy it. Rather, it was stated they wanted planes that they could run cheaper rather than faster. Especially in light of the fact that passengers wanted to pay less and less and the amount of travel (number of traveling passengers) has declined since 9-11. But, thankfully your BS means we can ignore statements like that. Thankfully, you know more than the carriers. Thank god. We're saved! Ignoring your BS, I think the carrier's statements directly boils down to one of simple economics. Which, just so you can understand, people want cheaper tickets, not faster transport. Well, they want faster transport, but the paying public isn't willing to pay for it. Either way, that screams of simple economics.
Worse, you seem completely confused between military need/directive versus private and/or commercial economic forces.
It wasn't fun discoursing with you; your arguments lack of structure and depth was compounded by your ad hominem attack.
LOL! Thankfully you have a BS because it's all that you seem to know. Back on planet earth, economics are a huge driving force. Best of all, economics rarely have much to do with military matters.
Hopefully your pompous wind-bagging will allow the rest of the readers to ignore the rest of your insight provided by your egotistical BS degree.
Furthermore, the technology in question DOES NOT EXIST
Interesting. Seems all the aircraft designers seem to agree that you have a degree in BS.
Except that there isn't a lack of progress. That's the whole problem with you insane argument. A lack of technological progress is completely different from a lack of economic viability. The technology exists to easily do far better. The problem is one of simple economics. Where there is good enough technology to provide for he masses at reasonable rates, the need for a something better is drastically reduced. Heck, technology to reduce several hours of of transcon flight times, for the masses, easily exists, yet it's not economicaly viable in today's market.
What's sad, to me, is that you fail to see the obvious.
Moller has been schilling its vaporware for decades.
I doubt the word, "schilling", aptly applies here. He's a small company working on a tough problem. He's built and designed real technology. Granted, I do believe his last-mile technology efforts are stupid (pilotless...come on...we can't yet do that with cars), but the technology he's developed is very real. The problem I see is that he wants to charge something like 1/4-million+ per car and not require a pilot certificate. That isn't going to happen any time soon. Even with a proven autopilot, I doubt the FAA is ever going to approve a vehicle with such capabilities for pilotless operation. If it gets a tripple redundant autopilot, engines, and avionics, maybe, but then now we're talking about a completely different craft with costs in the millions. Ask any pilot how reliable the autopilot is. They'll tell you, failure isn't exactly uncommon. Worse, sometimes even the best autopilots make the wrong decision. Needless to say, a qualified pilot needs to be at the ready to correct for any number of failure possibilities.
As for the investment agreement, granted, I have not read it, but from what you're saying, it's hardly unexpected. Let's say that he's unable to get the funding he needs to get his (very expensive) vehicle to market. That means he has to shut the doors. What would he pay you with? Anytime you invest of speculative R&D, it's risky. To think otherwise is foolish. You want a guarantee or some kind, don't invest in speculative R&D efforts. Just the same, it's those ventures that pose the highest risks that pose the highest possible returns. The choice is yours.
People often forget or simply don't understand the maintenance costs associated with planes. Standard jets have to be periodically taken apart, down to just their skin, and x-rayed to check for stressed areas. Engines have to be periodically taken apart and rebuilt. Instrumentation goes bad, as do sensors. All of which have to be replaced and/or repaired.
These are all costs which can very quickly add up. Add in the fact that the concord is pretty much a one of a kind and that it's super sonic, and I'd hazzard a guess that some types of standard maintenance were on an accelerated schedule, thus adding to additional operational costs.
For a small, single engine, piston plane, standard operational costs can quickly add up. Not including costs, such as fuel and oil. For a Cessna 172, expect to add an extra $20-$60 per hour to account to misc. operating costs. Just imagine what those add up to be on a very complex and high power plane such as the concord.
I think I've explained this twice now. You're full of BS. I've directly asked you to explain why being multithreaded translates to higher performance or even higher scalability.
It's rather obvious that you have no idea what you're talking about and you are simply parroting something that some pro-MySQL site told you. Simple fact is, being multithreaded, on most platforms, directly translates to slower performance. That's a fact. The significant expection to that fact is the Windows platform as MS hugely biased performance to allow for threaded applications to excel. Having said that, it's still rather easy to make a higherly threaded application perform like crap.
Add in the fact that threaded programming usually requires a significant amount of additional locking (which is costly) compared to a process model and shared memory. This directly translates, even when talking about Windows, to a significant amount resource contention on a per thread basis. In otherwords, any speed advantage gained from a threaded model, compared to a process model, is usually lost in simple locking contention.
That's the facts. What does this mean? It means that most threaded applications are always going to perform on par with process based application. Anyone that says otherwise, better be stating specific exceptions for specific corner cases, otherwise they are lying their butts off.
Care to counter or are you willing to admit you don't have any idea about which you speak? Now then, for the third time, specifically and exactly how has a process model hurt the performance of PostgreSQL?
What evidence am I disputing? Everything I stated is based on information directly provided from the review and direct knowledge and understanding of the various RDBMS systems and their features.
Please, be direct. What did I miss?
This should be good. It's going to be far easier for you to just admit you were either cheerleading or simply mistaken, than to dispute the facts. The fact is, MySQL is a dog and they went out of their way to create a test which falsely pushed MySQL into the lead. In other words, either they rigged the tests or they were incompetent. take your pick. Honestly, PCMag has a very, very long history of being incompetent with any moderately complex benchmark, so in their own defense, chances are high that they were simply incompetent rather than a willful attempt to mislead.
Here are the facts directly taken from the review: ASE has broken JDBC drivers and they changed the test to double it's workload so they could work around it. MSSQL and Oracle went untuned. MSSQL also had a bad JDBC driver, which was in beta testing at the time. They did not used stored procudures even though it may have dramatically sped all of the databases up, save only MySQL. And that's because MySQL doesn't support them. They did not use prepared queries even though it may have dramatically sped all of the databases up, save only MySQL. And that's because MySQL doesn't support them. They then turned on a feature in MySQL (query cache), which could of easily been emulated in ALL of the databases by simple means of one extra table and a couple of stored procedures. But, they decided to slant the results toward MySQL. They then reduced the number of connections allowed to MySQL, thusly further reducing the contention within the database. That directly translates to falsely elevating its scalability statistics.
So, there's the simple facts. Are you now saying that the facts from the article are wrong because you'd have to admit you were wrong?
Oracle and MS SQL went untuned. Everyone knows Oracle requires good tuning. ASE tests were done with a crappy JDBC driver. As was MS's database. In fact, they used a beta driver for MS. Rightly so, many are calling this a JDBC test, moreso than anything else.
It gets better! LOL! Just wait!
They differed the number of allowed database connections per database. That's a huge variable right there. That alone, is reason enough to invalidate the whole friggen test. That one variable will greatly effect the amount of contention in each database. What a joke.
But wait...there's more...
"the throughput leveled off or declined, or the number of errors exceeded 10 percent."
Errors! What friggen errors!?!? There should be no errors, let alone 10%! Yet, they don't explain further. What crap. If they have any noteworthy percent in errors, or even an allowance for, they screams that they don't have things configured and running properly. Period.
They did allow for index and optmizer tweaking, but MS and Oracle went untuned. Ack! What garbage this is!
Oh wait...this is awesome. They doubled the work for ASE because they were having problems with the JDBC drivers. This really is a JDBC test drive and in no way reflects actual database performance. What a joke.
"At the bottom of the heap on the JSP test was Microsoft SQL Server 2000, with a peak of 209 pages per second. This was probably the result of a poorly performing JDBC driver that's still in beta. We tried a newer version of the JDBC driver supplied by Microsoft, but this had no impact on performance."
Ya, that and the fact that you didn't have anyone tuning the friggen database. Plus, you didn't bother to implement a static query cache. Plus, you didn't bother to implement prepared queries. Plus, you didn't have anyone tuning the friggen queries. What a friggen joke!
Plus, they state early on that they allocate memory to allow for connections up to what memory allows for yet they have memory left over for cache and reduce the number of connections (contention) in MySQL, further biasing the results. This is nothin but a sad friggen joke. Only dolts and idiots are going to think these tests have any meaning at all. They don't. Hell, three vendors are knocked right out, before the testing ever started, because of the stupidity of it all. But, if MySQL guys want to claim victory in a fixed and biased test, more power to them. What a friggen joke.
One also has to wonder how much of the test queries could of been implemented as stored procedures. All of the databases, save MySQL, support this feature. Doing so can often make huge performance differences. In some cases, it can make an order of magnitude difference. But hey, we all know this MySQL baised test actually means something. Oh well. Then, they completely ignore prepared queries, which can make a huge difference on systems that are under a load. But, oh well. They really didn't want to compare performance at all. At least not on a level playing field.
And, I'm just scratching the surface!
In short, if you really think this test really validates MySQL in any way, you are an absoluete moron. I can only hope that you are not a DBA. If you are, you should do your company a favor and and jump off a cliff because you are unfit for DBA duty.
Since the use of the cache results in a 33% performance boost, it's obvious that it's mostly a select only environment. To be fair, they should of implemented this cached result behavior in all the other databases by the use of a stored procedure or two, one extra table and a simple trigger. Had they done this, all of the other databases would of seen something like an extra 33% improvement in performance.
Basically, the fact that they had to use the cache to hide the poor performance of MySQL, speaks loudly. Had they bothered to level the playing field, as expected, MySQL would of been last or nearly last in this round up. This ignores the fact that they didn't use prepared queries in all of the databases that support them. Again, this would of further placed MySQL in last place as it doesn't support prepared queries.
Long story short, the provided link proves two things: One, PCMag continues its long history at poorly benchmarking anything that is complex. Two, MySQL is a dog of a performer.
Everytime the dataset is updated, the cached result set has to be updated. Everytime this happenes, the performance of the DB is going to be as if the cache were disabled. The fact that there isa 1/3 difference in performance speaks loudly that, by far, the result set being obtained is fairly static. Otherwise, the cache would be worthless.
Along those lines, to be fair, each database that did not have a cache feature, should have been using a "cached" result table, whereby, they selected the result into the table and then returned the result set until the result set had changed. Basically emulating this feature. But, I guess they didn't want to be fair. Along those lines, since most (all) all other of those DB's cold EASILY implement a cached strategy, in the databaes, by simple use of triggers. But, I guess they didn't want to have an even playing field.
As for prepared queries, those can and often do make a huge difference on a system that is under load. Period. For PostgreSQL, the difference isn't as large as some DBs, but it is very noticeable, especially on load tests. This leads to significant differences on a heavily loaded system. Typical improvements, especially on moderately simple and very complex queries, can translate to 10% to 20%. Especially so when the returned results sets are small, quickly obtained by the DB, and quickly returned. Prepared queries don't make sense when it takes long periods of time to result a complete result set. On the other hand, such queries wouldn't make sense in a web serving environment. As such, it's VERY safe to say that the return on preformance would of been large.
The point, which you've obviously managed to close your mind and eyes, to ignore is that these are hardly representative of any of those DB's, and the tests is, very biased toward MySQL. The second that they decided to use cached results to hide a significant performance issues (yes, 33% is significant), if they wanted to remain unbiased, they should of invested effort , at a minimum, to do the very common (sense) items to all of the other databases as well. The fact that they ignored prepared queries makes it very easy to understand that the purpose of the tests were to be biased. After all, AFAIK, all of those databases, save MySQL, support such a feature. Accordingly, it's unforigvably moronic that they ignored such a common and obvious feature. But, since the objective was to be biased, it's obvious why it happened.
After it's all said and done, you can either grow up and face facts for continue to be jealous (for whatever crazy reason) of other database solutions. Until you make such an effort, it's obvious that you're not doing anything but showing off your ignorance and trolling in general.
The fact that my id is an issue to you, wonderfully highlights just how closed minded and biased you are. Need I say more. It's one thing if I stated anything that wasn't true. I didn't. It's another thing to ignore a statement, no matter how true, just because you don't like the messenger. How petty. You have my pitty.
I think at this point, anyone that stumbles on those portion of the thread will easily ignore anything you've stated for many reasons. One, you offered no facts or anything that is supported by database reality. And two, you come off as nothing but an ignorant sour grape. I think others, as I have, will easily see right through you.
You might bother to read the article. It appears you are full of BS.
MySQL used Inno, MyISAM and cached results. News flash! MySQL's cached results are only of value when the result sets rarely change. This proves that it was a select only operatoin. Worth noting, that every result set delivered from cache, avoids MySQL's horrible scaling issues. Issues, I might add became very obvious when the cache was disabled. According to the results, they preformed only 2/3 as good without the cache enabled. I think that speaks loud and clear as to the performance of MySQL. Especially given that given MySQL BEST FRIGGEN CATEGORY, without the cache, they are a full 1/3 slower. Putting that into perspective, that places them in second or third FROM LAST in the area where its as its best! The next question is to find out if any of the queries were optimized (as it doesn't appear to say) rather than using the least common donominator (broken-MySQL-SQL). Chances are high, each of the databases, save MySQL, were using far for optimal SQL.
It also appears, exactly as I feared, that they ignore all of the significant performance features offered by all of the other databases. Specifically, it does not appear that they properly converted their queries to prepared queries. On a load test, that can make a HUGE difference in performance as it prevents each engine from constantly having to reparse the queries. AFAIK, MySQL is the only DB that doesn't support that feature yet all of them were forced to slow down because MySQL doesn't support them. Combine all these with the simple fact that they enabled result set cache means that the results are worthless. The closest result set you can get would be, by simple estimates, would be to adjust MySQL's peformance downward by 33% and all the others up at least 20%. Even without adding a 20% estimate, which is reflective of the benchmarker's incompetence, MySQL quickly finds it self at the back of the pack. Wow. What a friggen surprise.
Long story short, you can call BS all you want. The only problem here is that the results are biased and are complete BS. Either you'll make an effort to learn more about their invalid conclusions and you can continue to be deluded. The choice is yours. The only conclussion that anyone who actually understands RDBMS can draw from this is that MySQL is still a slow performer and that the results are horribly biased toward MySQL.
Are we supposed to think that statement means something? You do realize that aolserver was written to be fast, above all else. Apache was written to be robust and portable, above all else. The simple fact that Apache is still wicked fast pretty well says all that needs to be said.
I simply stated that not being multi threaded limits the performance of postgres.
In what way? Again, I'm forced to ask. Even in MySQL's best performance cases, it's generally not hugely faster than PostgreSQL. Why? Simple fact is, PostgreSQL has much more complex functionality and many more code paths. It's to be expected that this is going to have some runtime costs associated with it. Just the same, according to your logic, MySQL should always be faster because it implements a threading model. Contrary to that logic, PostgreSQL's process model out scales MySQL's threading model, in spite of the fact that it's executing more code. Hmmm. I guess we can pretty well ignore your theory and call it what it is. Garage.
Finally there is no law that says that threaded applications are inherently less stable.
Law? No. Fact? Yes. The threading model requirements mandated on MS platforms is often pointed at for being a primary reason of lower uptimes and lower application availability. Worse, in MS' case, thread level resource issues tend to be tied up for the life of the process. This means, if a thread segs and the process is kind enough to catch it, any leaked resources from that thread will remain leaked (or locked, as it pertains to DLLs) until the process exits. This, in turn, raises questions of system uptime, beyond that of application uptime.
As I said virtually every other database in the marketplace is multithreaded including some renknowned for their stability and reliability like oracle, db/2, mssql server,
All have had bugs, PostgreSQL included. All have crashed at some point in time. The question is, did a single session crash the whole database? In PostgreSQL's case, the answer is no. In all the others you named, the answer is, quite likely. Furthermore, you can ask, did a single session corrupt one or more sessions, when using a threading model? The answer is, it's possible.
If forking were truly advantagous you'd think oracle or IBM would have made their database forking by now.
Or, maybe economics, as with any company, is a deciding factor. I don't think you realize the cost and effort that would be involved in converting from one model to another. As with any point of contention, it's often about risk management. Are the risks being mitigated? Are tools available to fix the resulting corruptions, when they occur?
Everything you're saying is based on process-level protection provided by the OS.
Exactly. The OS is helping to ensure database integrity.
If the OS provides sufficently correct thread-level protection, then almost all of those issues become a dead heat.
Except, it's impossible for the OS to sufficently correct for thread-level protection while still providing the advantages in speed of thread level IPCs. So, it's safe to say, it's impossible for a threaded implementation to, "become a dead heat", with a process based implementation in that regard.
Also, it's not just spinning a thread vrs forking a process - process-level IPC is slower than thread-level IPC as well.
This is true. Just the same, thread level implementations tend to require more IPC synchronization, thusly, on average, the threading IPC speed advantages tend to become noise. This is because threaded implementations tend to have much higher levels of contention on shared resources. On average, I'd consider it to be a wash.
And process-level IPC is no safer than thread-level.
I'm sorry, but this doesn't entirely address the issues. Have a shared resource on the stack? IF you walk on the stack, you potentially just corrupted state for ALL threads and brought the state of the entire process into question. The same holds true for shared data segments.
If one of your processes corrupts and crashes during a write, your database is just as hosed as if a thread did it.
Maybe, maybe not. This is why we have transactions. If the corrupt transaction fails to complete, it's rolled back. Conistency is maintained. On the other hand, it's very possible, in a threaded implementation, to actually have the field value corrupted (it's length or value, etc), and have it still be written to disk. In otherwords, as I originally stated, a process implementation greatly reduces the chances for corruption. I did not state it eliminated it.
On Windows, at least, threading is far more performant - you _must_ thread for very fast IO, network or disk.
Because MS made the decision to bais threads over processes. On Linux, even with the old thread implementations, threads were really LWP and were not significantly faster at spawning than processes. That was because forking on Linux so fast compared to other platforms.
Now that linux has a non-crap thread library, that may end up being true there also.
Well, that addresses Linux and threads, nothing else. Remember, PostgreSQL runs on many more platforms than just Linux. It's always going to be a toss up on other Unix platforms to determine which is best (threads vs process). This is exactly why Apache 2.x implemented it's hybrid model. That is, so that they would be fast on MS' platform and fast on Unix platforms, allowing each to tune best for each unique platform.
The most reliable and performant databases in the world are threaded - thats a logical argument in favor of threading.
Bzzz. Popularity hardly makes right. Best of all, popularity hardly invalidates the issues which I put forth when contrasting the two models.
Bluntly, neither model is perfect. Just the same, it's far *easier* to maintain consistency, uptime, and reliability with a process implementation. Notice that none of those speak to performance. Even if you refuse to accept that threading is not inherently faster than processes, which is more important to you? ACID or speed?
Slashdot Mirror
The sonic cruiser was killed by simple investor caution combined with lack of information, not economics. And Boeing's new proposal has no significant selling point over the alternatives offered by Airbus.
That's interesting. At the time, it was widely offered that it fell through because the carriers were not going to buy it. Rather, it was stated they wanted planes that they could run cheaper rather than faster. Especially in light of the fact that passengers wanted to pay less and less and the amount of travel (number of traveling passengers) has declined since 9-11. But, thankfully your BS means we can ignore statements like that. Thankfully, you know more than the carriers. Thank god. We're saved! Ignoring your BS, I think the carrier's statements directly boils down to one of simple economics. Which, just so you can understand, people want cheaper tickets, not faster transport. Well, they want faster transport, but the paying public isn't willing to pay for it. Either way, that screams of simple economics.
Worse, you seem completely confused between military need/directive versus private and/or commercial economic forces.
It wasn't fun discoursing with you; your arguments lack of structure and depth was compounded by your ad hominem attack.
LOL! Thankfully you have a BS because it's all that you seem to know. Back on planet earth, economics are a huge driving force. Best of all, economics rarely have much to do with military matters.
Hopefully your pompous wind-bagging will allow the rest of the readers to ignore the rest of your insight provided by your egotistical BS degree.
Furthermore, the technology in question DOES NOT EXIST
Interesting. Seems all the aircraft designers seem to agree that you have a degree in BS.
Except that there isn't a lack of progress. That's the whole problem with you insane argument. A lack of technological progress is completely different from a lack of economic viability. The technology exists to easily do far better. The problem is one of simple economics. Where there is good enough technology to provide for he masses at reasonable rates, the need for a something better is drastically reduced. Heck, technology to reduce several hours of of transcon flight times, for the masses, easily exists, yet it's not economicaly viable in today's market.
What's sad, to me, is that you fail to see the obvious.
My thoughts, exactly!
Seems someone is living in a different reality than the rest of us.
Moller has been schilling its vaporware for decades.
I doubt the word, "schilling", aptly applies here. He's a small company working on a tough problem. He's built and designed real technology. Granted, I do believe his last-mile technology efforts are stupid (pilotless...come on...we can't yet do that with cars), but the technology he's developed is very real. The problem I see is that he wants to charge something like 1/4-million+ per car and not require a pilot certificate. That isn't going to happen any time soon. Even with a proven autopilot, I doubt the FAA is ever going to approve a vehicle with such capabilities for pilotless operation. If it gets a tripple redundant autopilot, engines, and avionics, maybe, but then now we're talking about a completely different craft with costs in the millions. Ask any pilot how reliable the autopilot is. They'll tell you, failure isn't exactly uncommon. Worse, sometimes even the best autopilots make the wrong decision. Needless to say, a qualified pilot needs to be at the ready to correct for any number of failure possibilities.
As for the investment agreement, granted, I have not read it, but from what you're saying, it's hardly unexpected. Let's say that he's unable to get the funding he needs to get his (very expensive) vehicle to market. That means he has to shut the doors. What would he pay you with? Anytime you invest of speculative R&D, it's risky. To think otherwise is foolish. You want a guarantee or some kind, don't invest in speculative R&D efforts. Just the same, it's those ventures that pose the highest risks that pose the highest possible returns. The choice is yours.
Flying cars being sold from reputable Web site for $20,000 RIGHT NOW
;)
You left off a digit. It should read:
Flying cars being sold from reputable Web site for $220,000 RIGHT NOW.
That's friggen funny!
I think that says a lot about NYC!
I'm sorry, but for diss'n the SR-71, you must be trolling. ;)
(whispering)Ya, you're right that the XB-70 is sweet looking.
(yelling)He's a troll! He spoke badly of the SR-71! Kill the witch! Burn the witch!
Cheers!
People often forget or simply don't understand the maintenance costs associated with planes. Standard jets have to be periodically taken apart, down to just their skin, and x-rayed to check for stressed areas. Engines have to be periodically taken apart and rebuilt. Instrumentation goes bad, as do sensors. All of which have to be replaced and/or repaired.
These are all costs which can very quickly add up. Add in the fact that the concord is pretty much a one of a kind and that it's super sonic, and I'd hazzard a guess that some types of standard maintenance were on an accelerated schedule, thus adding to additional operational costs.
For a small, single engine, piston plane, standard operational costs can quickly add up. Not including costs, such as fuel and oil. For a Cessna 172, expect to add an extra $20-$60 per hour to account to misc. operating costs. Just imagine what those add up to be on a very complex and high power plane such as the concord.
Interesting.
Please share more info as you can.
Who modded this as insightful?
The whole friggen point of the article is that it uses LESS energy.
So, yes, assuming it's true, it is the smart.
The original message was very polite. Thusly, showing the fear of those mysql-loving guys.
Which was exactly my whole point.
Umm...compared to the galaxy. Yes.
Thusly, you can compare MySQL and PostgreSQL and wind up with the proper answer using the comparison and answer I provided above.
Go figure.
I think I've explained this twice now. You're full of BS. I've directly asked you to explain why being multithreaded translates to higher performance or even higher scalability.
It's rather obvious that you have no idea what you're talking about and you are simply parroting something that some pro-MySQL site told you. Simple fact is, being multithreaded, on most platforms, directly translates to slower performance. That's a fact. The significant expection to that fact is the Windows platform as MS hugely biased performance to allow for threaded applications to excel. Having said that, it's still rather easy to make a higherly threaded application perform like crap.
Add in the fact that threaded programming usually requires a significant amount of additional locking (which is costly) compared to a process model and shared memory. This directly translates, even when talking about Windows, to a significant amount resource contention on a per thread basis. In otherwords, any speed advantage gained from a threaded model, compared to a process model, is usually lost in simple locking contention.
That's the facts. What does this mean? It means that most threaded applications are always going to perform on par with process based application. Anyone that says otherwise, better be stating specific exceptions for specific corner cases, otherwise they are lying their butts off.
Care to counter or are you willing to admit you don't have any idea about which you speak? Now then, for the third time, specifically and exactly how has a process model hurt the performance of PostgreSQL?
I couldn't resist.
What evidence am I disputing? Everything I stated is based on information directly provided from the review and direct knowledge and understanding of the various RDBMS systems and their features.
Please, be direct. What did I miss?
This should be good. It's going to be far easier for you to just admit you were either cheerleading or simply mistaken, than to dispute the facts. The fact is, MySQL is a dog and they went out of their way to create a test which falsely pushed MySQL into the lead. In other words, either they rigged the tests or they were incompetent. take your pick. Honestly, PCMag has a very, very long history of being incompetent with any moderately complex benchmark, so in their own defense, chances are high that they were simply incompetent rather than a willful attempt to mislead.
Here are the facts directly taken from the review:
ASE has broken JDBC drivers and they changed the test to double it's workload so they could work around it. MSSQL and Oracle went untuned. MSSQL also had a bad JDBC driver, which was in beta testing at the time. They did not used stored procudures even though it may have dramatically sped all of the databases up, save only MySQL. And that's because MySQL doesn't support them. They did not use prepared queries even though it may have dramatically sped all of the databases up, save only MySQL. And that's because MySQL doesn't support them. They then turned on a feature in MySQL (query cache), which could of easily been emulated in ALL of the databases by simple means of one extra table and a couple of stored procedures. But, they decided to slant the results toward MySQL. They then reduced the number of connections allowed to MySQL, thusly further reducing the contention within the database. That directly translates to falsely elevating its scalability statistics.
So, there's the simple facts. Are you now saying that the facts from the article are wrong because you'd have to admit you were wrong?
LOL.
That's what I thought. Facts are a hard thing to dispute. It's easier to walk off than admit your wrong.
Oh well.
I'm actually reading the review in detail. LOL!
What a friggen joke!!
Oracle and MS SQL went untuned. Everyone knows Oracle requires good tuning. ASE tests were done with a crappy JDBC driver. As was MS's database. In fact, they used a beta driver for MS. Rightly so, many are calling this a JDBC test, moreso than anything else.
It gets better! LOL! Just wait!
They differed the number of allowed database connections per database. That's a huge variable right there. That alone, is reason enough to invalidate the whole friggen test. That one variable will greatly effect the amount of contention in each database. What a joke.
But wait...there's more...
"the throughput leveled off or declined, or the number of errors exceeded 10 percent."
Errors! What friggen errors!?!? There should be no errors, let alone 10%! Yet, they don't explain further. What crap. If they have any noteworthy percent in errors, or even an allowance for, they screams that they don't have things configured and running properly. Period.
They did allow for index and optmizer tweaking, but MS and Oracle went untuned. Ack! What garbage this is!
Oh wait...this is awesome. They doubled the work for ASE because they were having problems with the JDBC drivers. This really is a JDBC test drive and in no way reflects actual database performance. What a joke.
"At the bottom of the heap on the JSP test was Microsoft SQL Server 2000, with a peak of 209 pages per second. This was probably the result of a poorly performing JDBC driver that's still in beta. We tried a newer version of the JDBC driver supplied by Microsoft, but this had no impact on performance."
Ya, that and the fact that you didn't have anyone tuning the friggen database. Plus, you didn't bother to implement a static query cache. Plus, you didn't bother to implement prepared queries. Plus, you didn't have anyone tuning the friggen queries. What a friggen joke!
Plus, they state early on that they allocate memory to allow for connections up to what memory allows for yet they have memory left over for cache and reduce the number of connections (contention) in MySQL, further biasing the results. This is nothin but a sad friggen joke. Only dolts and idiots are going to think these tests have any meaning at all. They don't. Hell, three vendors are knocked right out, before the testing ever started, because of the stupidity of it all. But, if MySQL guys want to claim victory in a fixed and biased test, more power to them. What a friggen joke.
One also has to wonder how much of the test queries could of been implemented as stored procedures. All of the databases, save MySQL, support this feature. Doing so can often make huge performance differences. In some cases, it can make an order of magnitude difference. But hey, we all know this MySQL baised test actually means something. Oh well. Then, they completely ignore prepared queries, which can make a huge difference on systems that are under a load. But, oh well. They really didn't want to compare performance at all. At least not on a level playing field.
And, I'm just scratching the surface!
In short, if you really think this test really validates MySQL in any way, you are an absoluete moron. I can only hope that you are not a DBA. If you are, you should do your company a favor and and jump off a cliff because you are unfit for DBA duty.
Not really.
Since the use of the cache results in a 33% performance boost, it's obvious that it's mostly a select only environment. To be fair, they should of implemented this cached result behavior in all the other databases by the use of a stored procedure or two, one extra table and a simple trigger. Had they done this, all of the other databases would of seen something like an extra 33% improvement in performance.
Basically, the fact that they had to use the cache to hide the poor performance of MySQL, speaks loudly. Had they bothered to level the playing field, as expected, MySQL would of been last or nearly last in this round up. This ignores the fact that they didn't use prepared queries in all of the databases that support them. Again, this would of further placed MySQL in last place as it doesn't support prepared queries.
Long story short, the provided link proves two things: One, PCMag continues its long history at poorly benchmarking anything that is complex. Two, MySQL is a dog of a performer.
You really are a joke.
Everytime the dataset is updated, the cached result set has to be updated. Everytime this happenes, the performance of the DB is going to be as if the cache were disabled. The fact that there isa 1/3 difference in performance speaks loudly that, by far, the result set being obtained is fairly static. Otherwise, the cache would be worthless.
Along those lines, to be fair, each database that did not have a cache feature, should have been using a "cached" result table, whereby, they selected the result into the table and then returned the result set until the result set had changed. Basically emulating this feature. But, I guess they didn't want to be fair. Along those lines, since most (all) all other of those DB's cold EASILY implement a cached strategy, in the databaes, by simple use of triggers. But, I guess they didn't want to have an even playing field.
As for prepared queries, those can and often do make a huge difference on a system that is under load. Period. For PostgreSQL, the difference isn't as large as some DBs, but it is very noticeable, especially on load tests. This leads to significant differences on a heavily loaded system. Typical improvements, especially on moderately simple and very complex queries, can translate to 10% to 20%. Especially so when the returned results sets are small, quickly obtained by the DB, and quickly returned. Prepared queries don't make sense when it takes long periods of time to result a complete result set. On the other hand, such queries wouldn't make sense in a web serving environment. As such, it's VERY safe to say that the return on preformance would of been large.
The point, which you've obviously managed to close your mind and eyes, to ignore is that these are hardly representative of any of those DB's, and the tests is, very biased toward MySQL. The second that they decided to use cached results to hide a significant performance issues (yes, 33% is significant), if they wanted to remain unbiased, they should of invested effort , at a minimum, to do the very common (sense) items to all of the other databases as well. The fact that they ignored prepared queries makes it very easy to understand that the purpose of the tests were to be biased. After all, AFAIK, all of those databases, save MySQL, support such a feature. Accordingly, it's unforigvably moronic that they ignored such a common and obvious feature. But, since the objective was to be biased, it's obvious why it happened.
After it's all said and done, you can either grow up and face facts for continue to be jealous (for whatever crazy reason) of other database solutions. Until you make such an effort, it's obvious that you're not doing anything but showing off your ignorance and trolling in general.
The fact that my id is an issue to you, wonderfully highlights just how closed minded and biased you are. Need I say more. It's one thing if I stated anything that wasn't true. I didn't. It's another thing to ignore a statement, no matter how true, just because you don't like the messenger. How petty. You have my pitty.
I think at this point, anyone that stumbles on those portion of the thread will easily ignore anything you've stated for many reasons. One, you offered no facts or anything that is supported by database reality. And two, you come off as nothing but an ignorant sour grape. I think others, as I have, will easily see right through you.
Slashdot is known to have serious downtime and periodic performance issues.
;)
If that's "Big-time" enough for you, well...it's safe to say that such a thought scares me.
Wow. Some idiot MySQL guy got some mod points and he's trying to punish me. Oh no. What a loser.
All good points!
You might bother to read the article. It appears you are full of BS.
MySQL used Inno, MyISAM and cached results. News flash! MySQL's cached results are only of value when the result sets rarely change. This proves that it was a select only operatoin. Worth noting, that every result set delivered from cache, avoids MySQL's horrible scaling issues. Issues, I might add became very obvious when the cache was disabled. According to the results, they preformed only 2/3 as good without the cache enabled. I think that speaks loud and clear as to the performance of MySQL. Especially given that given MySQL BEST FRIGGEN CATEGORY, without the cache, they are a full 1/3 slower. Putting that into perspective, that places them in second or third FROM LAST in the area where its as its best! The next question is to find out if any of the queries were optimized (as it doesn't appear to say) rather than using the least common donominator (broken-MySQL-SQL). Chances are high, each of the databases, save MySQL, were using far for optimal SQL.
It also appears, exactly as I feared, that they ignore all of the significant performance features offered by all of the other databases. Specifically, it does not appear that they properly converted their queries to prepared queries. On a load test, that can make a HUGE difference in performance as it prevents each engine from constantly having to reparse the queries. AFAIK, MySQL is the only DB that doesn't support that feature yet all of them were forced to slow down because MySQL doesn't support them. Combine all these with the simple fact that they enabled result set cache means that the results are worthless. The closest result set you can get would be, by simple estimates, would be to adjust MySQL's peformance downward by 33% and all the others up at least 20%. Even without adding a 20% estimate, which is reflective of the benchmarker's incompetence, MySQL quickly finds it self at the back of the pack. Wow. What a friggen surprise.
Long story short, you can call BS all you want. The only problem here is that the results are biased and are complete BS. Either you'll make an effort to learn more about their invalid conclusions and you can continue to be deluded. The choice is yours. The only conclussion that anyone who actually understands RDBMS can draw from this is that MySQL is still a slow performer and that the results are horribly biased toward MySQL.
I would like to add that I'm fairly sure the original post is a troll. I don't expect a follow up response at all.
;)
But, just in case....trying to be helpful isn't a crime.
Apache is slower then aolserver.
Are we supposed to think that statement means something? You do realize that aolserver was written to be fast, above all else. Apache was written to be robust and portable, above all else. The simple fact that Apache is still wicked fast pretty well says all that needs to be said.
I simply stated that not being multi threaded limits the performance of postgres.
In what way? Again, I'm forced to ask. Even in MySQL's best performance cases, it's generally not hugely faster than PostgreSQL. Why? Simple fact is, PostgreSQL has much more complex functionality and many more code paths. It's to be expected that this is going to have some runtime costs associated with it. Just the same, according to your logic, MySQL should always be faster because it implements a threading model. Contrary to that logic, PostgreSQL's process model out scales MySQL's threading model, in spite of the fact that it's executing more code. Hmmm. I guess we can pretty well ignore your theory and call it what it is. Garage.
Finally there is no law that says that threaded applications are inherently less stable.
Law? No. Fact? Yes. The threading model requirements mandated on MS platforms is often pointed at for being a primary reason of lower uptimes and lower application availability. Worse, in MS' case, thread level resource issues tend to be tied up for the life of the process. This means, if a thread segs and the process is kind enough to catch it, any leaked resources from that thread will remain leaked (or locked, as it pertains to DLLs) until the process exits. This, in turn, raises questions of system uptime, beyond that of application uptime.
As I said virtually every other database in the marketplace is multithreaded including some renknowned for their stability and reliability like oracle, db/2, mssql server,
All have had bugs, PostgreSQL included. All have crashed at some point in time. The question is, did a single session crash the whole database? In PostgreSQL's case, the answer is no. In all the others you named, the answer is, quite likely. Furthermore, you can ask, did a single session corrupt one or more sessions, when using a threading model? The answer is, it's possible.
If forking were truly advantagous you'd think oracle or IBM would have made their database forking by now.
Or, maybe economics, as with any company, is a deciding factor. I don't think you realize the cost and effort that would be involved in converting from one model to another. As with any point of contention, it's often about risk management. Are the risks being mitigated? Are tools available to fix the resulting corruptions, when they occur?
Everything you're saying is based on process-level protection provided by the OS.
Exactly. The OS is helping to ensure database integrity.
If the OS provides sufficently correct thread-level protection, then almost all of those issues become a dead heat.
Except, it's impossible for the OS to sufficently correct for thread-level protection while still providing the advantages in speed of thread level IPCs. So, it's safe to say, it's impossible for a threaded implementation to, "become a dead heat", with a process based implementation in that regard.
Also, it's not just spinning a thread vrs forking a process - process-level IPC is slower than thread-level IPC as well.
This is true. Just the same, thread level implementations tend to require more IPC synchronization, thusly, on average, the threading IPC speed advantages tend to become noise. This is because threaded implementations tend to have much higher levels of contention on shared resources. On average, I'd consider it to be a wash.
And process-level IPC is no safer than thread-level.
I'm sorry, but this doesn't entirely address the issues. Have a shared resource on the stack? IF you walk on the stack, you potentially just corrupted state for ALL threads and brought the state of the entire process into question. The same holds true for shared data segments.
If one of your processes corrupts and crashes during a write, your database is just as hosed as if a thread did it.
Maybe, maybe not. This is why we have transactions. If the corrupt transaction fails to complete, it's rolled back. Conistency is maintained. On the other hand, it's very possible, in a threaded implementation, to actually have the field value corrupted (it's length or value, etc), and have it still be written to disk. In otherwords, as I originally stated, a process implementation greatly reduces the chances for corruption. I did not state it eliminated it.
On Windows, at least, threading is far more performant - you _must_ thread for very fast IO, network or disk.
Because MS made the decision to bais threads over processes. On Linux, even with the old thread implementations, threads were really LWP and were not significantly faster at spawning than processes. That was because forking on Linux so fast compared to other platforms.
Now that linux has a non-crap thread library, that may end up being true there also.
Well, that addresses Linux and threads, nothing else. Remember, PostgreSQL runs on many more platforms than just Linux. It's always going to be a toss up on other Unix platforms to determine which is best (threads vs process). This is exactly why Apache 2.x implemented it's hybrid model. That is, so that they would be fast on MS' platform and fast on Unix platforms, allowing each to tune best for each unique platform.
The most reliable and performant databases in the world are threaded - thats a logical argument in favor of threading.
Bzzz. Popularity hardly makes right. Best of all, popularity hardly invalidates the issues which I put forth when contrasting the two models.
Bluntly, neither model is perfect. Just the same, it's far *easier* to maintain consistency, uptime, and reliability with a process implementation. Notice that none of those speak to performance. Even if you refuse to accept that threading is not inherently faster than processes, which is more important to you? ACID or speed?