It's a bit like prohibition basically -- everyone at the time thought it was a good idea, but no one lived up to it, and it turned out to be mind bogglingly stupid. We were best rid of it.
I'm not sure I buy into that statement. Prohibition ended because it created an even worse environment. It created far more criminals who broke far worse laws. Murder, extortion, racketeering, rising in lessor crimes and general violence. All with a reduction in tax income (IIRC). Worse, there were a number of cases where cops and judges were being paid of to allow violations to get off with minimal pain.
Until you can prove that p2p is causing murder, racketerring, people being beat up on the streets, or corrupt judges and police, it's fairly hard to even begin to compare the two.
Ya, I followed that thread too. I thought it was fairly interesting myself. Seems the kernel runs out of kernel memory to handle the kernel-like printf statement. The fix is to convert it to an iterative approach whereby, many smaller chucks of memory simple get reused. Appears the infrastructure was already in place from another part of the kernel. So, seems it will be a fairly quick fix for them.
I knew it wasn't a joke (or certainly hoped not) and immediately thought, WOW! Serious scalability!
Tons and tons of work has gone into 2.6 to make it fully NUMA aware and scalable. Last I heard, there were still some minor memory allocation node biases left in the scheduler, however, those are actively being worked on. Furthermore, they were considered corner cases and not general NUMA processing problem domains.
IIRC, one or more the developers has a 128 (or larger, I forget) CPU NUMA system that 2.6 periodically gets tested against. Many smaller NUMA systems are commonly used by several others. It seems that many, but not all of the NUMA optimizations, also help SMP systems as well. As such, the developers have not been shy about embracing it. When the O(1) scheduler was writen, it was a very short period of time before they started adding HT and NUMA optimizations to it.
What, you mean the rating system they used was completely worthless? What? You mean that Fox destroyed their own show? What? You mean that in spite of Fox being incompetent, they've had absolutely wonderful shows? What? You mean Futurama? Family Guy? didn't suck?
The executives at Fox are brain dead.
P.S. For the record, I tried watching that horrible show called Firefly. On the rare occation that I was able to watch it, in spite of Fox's best efforts, I must say, the show was horrible! I'm sorry, but cowboys in space is stupid. Seems I stand corrected. Fox actually did something right! Go figure.
I know some people went crazy over that show...why? Help me out here? Everything I saw was bad writing, bad stories, and hoakie anachronisms in space. I really enjoy good sci-fi. And generally, I can watch just about anything. Will someone please fill me in on what they thought was good about that horrible show? Please? I feel like I'm missing something....but my brain says I'm not.
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.
If performance is lacking that much, I would guess that it means you have some SQL that needs to be rewritten or made more "postgresql-ized". The optimizer makes some assumptions here and there and without changing SQL to what PostgreSQL likes, it can make bad plans. Any engine can. Having said that, any time you port SQL to another engine, you're going to have to expect to make SQL changes. Comparing optimized SQL on one platform with unoptimized results on another is rediculas. Which is, needless to say, pretty much what you're spelling out here in your results.
[...]but I just couldn't get reasonable performance out of the database without doing some serious SQL-rewriting
Understood. Some RDBMS actually have their optimizer rewrite queries, giving you the impression that it's good SQL when it should really be expressed in some other form. In other words, you'll probably have to change the query a little bit to optimize it for PostgreSQL.
putting optimizer hints into the queries is just too much
That's a good thing, considering, PostgreSQL doesn't support hints, nor do they plan to.
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
In the vast, vast majority of these cases, it's because people cast something to a differing type than what is indexed and rightly so, the optimizer ignores it. Generally speaking, simply changing to the proper or more sane cast corrects this issue. After doing so, performance generally rocks.
Databases with simple queries where results are not needed instantly would do well with PostgreSQL.
Actual real-world results and very, very large databases disagree with your assessment. MySQL's optimizer is pethetic. As bad as you seem to dislike PostgreSQL's, it's lightyears ahead of MySQL's, especially for complex queries.
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.
This is called, knowing your dependencies and bothering to test before it goes into production.
debugging a stored procedure or trigger is not easy.
Actually, stored procedures tend to be fairly easy to debug if you approach them correctly. Triggers, on the other hand, can be somewhat tricky. Then again, triggers should always be used sparingly.
people tend to forget about triggers and stored procedures; they're hidden logic that can cause no end of problems.
Sounds like serious abuse/misuse of the facilities. Used correctly, they are mana from heaven. It's a great place to enforce business rules and centralize common business logic. Done properly, they will save tons in application code, debugging and ease applicatoin migration issues. Of course, the problem comes when you need to migrate to another database.
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.
Yes, they are pretty much a vendor lock-in. That being said, how often are you changing database backends? Compared to how often clients tend to change, it's usually more than a fair trade.
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 deve
You were modded down because there are many incompetent people that get moderator points and have yet to figure out the proper and responsible way to use those points. With luck, metamoderation will help correct what was so obviously done incorrectly.
You've been modded as a troll because your position is untennable.
Regardless, that would make the moderator an idiot because that's not his role. His role is to help make interesting stuff float to the top. Likewise, make crap sink to the bottom. In this case, even though I disagree with the posting, it should of been left as is (rightly so) or mod'd interesting, because that's what it is. A troll, it certainly is not.
Just because a moderator disagrees with a posting is NOT cause for it to be mod'd as "troll" or "overrated". I'm constantly finding that when I meta-mod, there are tons of idiot moderators that I'm having to come behind and correct. In fact, I'd say, maybe 1 out of 4, or maybe 1 out of 6 meta-mods (series of modding mods) that I do, do I find that moderators have actually done their job correctly. The fact that you've answered as you have might indicate that you should pass on your next chance to moderate until you've read the moderation rules. Hint, hint.
While I don't agree with the comments, it clearly is not a "troll". I would of rated it interesting. I would, however, rate the moderator as "idiot" or "incompetent".
Like it or not moderators, your job is not to mod down things you disagree with. You job to to find and moderate interesting tidbits, opinions, and facts so that the population at large can better enjoy the more interestings stuff.
Can you give some benchmarks of when Innodb would be slower than Postgresql?
Actually, the problem isn't so much that you can point a finger at Innodb. Having said that, Innodb is slower than straight up MySQL tables. Aside from that, you need to remember that it's the overall design that's making the difference. PostgreSQL implements a scheme called versioning which greatly reduces the amount of table locking required (see mvcc for more information and explanation). Interestingly enough, this is very simular to what Oracle uses. Beyond that, PostgreSQL has an excellent caching mechanism which greatly helps reduce disk I/O.
No matter how fast you can access your tables, if you can't effectively determine a plan to access your tables, you're going to be slow. PostgreSQL has an excellent optimizing query planner. MySQL has nothing like it. This means that if you use queries which are more than, "select * from foo;", and have more than a couple of rows worth of data, or multiple indexes (multiple data paths) a query planner is probably going to be important to you. Furthermore, PostgreSQL's planner is highly tunable and the query plans are easily obtainable (for review, validation and optimization). Furthermore, the query planner even supports a genetic algorithm to aid optimizing data path access in even the most bizzar of production query requirements (see GA link for more information). To boot, the planner fully understands virtual I/O, physical I/O, indexes, various join types and algorithms, and is able to grok very complex queries fairly well. This is not to say it's perfect. It's not. Just the same, this feature alone is head and shoulders above MySQL. This is why tables joins is often an problem for MySQL's performance.
Is the scalability jokes you refered to, uses innodb?
Please keep in mind that I was being overly cynical. Just the same, most performance benchmarks which attempt to put MySQL in good light, attempt to minimize the use of Inno tables. The reason being, inno tables impose a performance hit because of the extra features (transactions, etc). Because of this, tests often attempt to NOT use innodb tables unless the test is specifically in place to validate transactional support and associated features. This means, that MySQL almost always looks wicked fast unless data validity is important to you. If it is, you take a performance hit. In both cases, hope you don't have to read and write data at the same time in the same tables. If you do, the table locking will shoot you in the foot. This, for both native and inno tables.
Can you give some example of what makes Postresql more scalable, beside being more sql compliant or closer to a "read rdbms"?
Well, being more SQL compliant really doesn't make it scalable. It's nice and all, but it doesn't do anything for scalability. It does, however, allow you to leverage generalize SQL expertise much more easily. Which, in turn, can translate to better performance.
Let's talk a little bit about performance and scalability. Performance is generally measured in the latency of asking for a result and the time it takes to get a *complete* result back. I stress complete here because somes tests improperly measure. In some cases, some RDBMS will attempt to start returning result sets VERY quickly in order to give the illusion that it's latency is very low, however, the total time for the operation is much, much higher. Thusly, we'll say time for a *complete* result set. In most cases, a partial result set is worthless or out of context until all of the data is available for analysis.
Scalability, on the other hand, is the ability to continue to delivery timely (low latency) results as the load increases. For a typical DB, load generally means inserts, updates and deletes, however, specific workload
Neither PosgreSQL or mySQL are full, complete, and utterly perfect implemtations of a database. Neither is Oracle, BTW.
I completely agree!
Back then, mySQL couldn't be beat for handling read-only
Actually, at the time, most real benchmarks proved that to be false. MySQL and several others performed some benchmarks, using the current version of MySQL and outdated versions of PostgreSQL. Futhermore, most tests were a single query against a database. The result, MySQL was wicked fast. This was done because most web guys didn't know anything about DB's and so they did what they thought was a good test. They tested what they knew. The tested a single query with a single user and it was, indeed fast. In fact, faster than PostgreSQL. The problem was, few people tested concurrent access (typical of web sites). Those that did found that the speed advantage of MySQL very quickly disappeared and PostgreSQL shinned wonderfully. To date, MySQL's performance myths still persist. The simple fact is, MySQL has never been a performing beast, as most people think. Simple fact is, even all those years ago, PostgreSQL almost always out performs and out scales MySQL at all but the most basic of SQL tasks. And so, it became lore that MySQL is wicked fast and that PostgreSQL is wicked slow, but feature rich.
Since those days, PostgreSQL has gotten much, much faster and now scales much, much better. MySQL, I believe has worked some on it's scalability, however, the last thing I saw, it's still far behind PostgreSQL for all but the most basic of SQL tasks.
That basis of comparison is no longer true.
The generally available comparisions were never true. Generally speaking, everything that MySQL ever put into print on benchmarks were lies or willful efforts to mislead and misrepresent the truth. Simple fact is, MySQL did everything they could to prevent being compared toe to toe with a modern PostgreSQL. It doesn't take a rocket scientist to figure out why that might be.
Day 1 you have a need, day 2 you actually research available solutions, and day 3 you declare a "winner" and it is forevermore cast in stone as the "one true solution". The fact masses of people tend to go thorugh the same process at basically the same time doesn't help. Thus the broad noise that mySQL is "the Answer(tm)".
Couldn't agree more. Worse, more often then not, the people picking the RDMBS solution are completely unqualified to make such a solution. Then, the legacy "winner" finds its self as the solution over and over again.
Anyway, postreSQL has always sought to compete in the full function space. Oracle was/is a much better "comparison" to postgreSQL than mySQL.
Absolutely correct!
Bottom line, if you invested in learning and implementing mySQL, and it is still working for you, then there is absolurely no need to be concerned with postgreSQL yet.
I'm not sure I buy 100% into that statement. Just the same, I think it rings true enough. I generally tell people, if you wouldn't use an Access DB for your solution, then you shouldn't use MySQL. The funny thing is, Access actually has a richer set of features than even MySQL does. I think the Access comparision comment still holds true today.
Yes, evaluate both, but don't assume mySQL or postgreSQL is "better" based on what you hear.
I strongly believe in "best tool for the job". As such, it is true that PostgreSQL may not be the best tool. Even the PostgreSQL developers will tell you that. Just the same, I often find that MySQL is rarely the best tool for the job. That's not to say that it's not a good SQL introduction and *maybe* as a learning tool, it might have value. The maybe is there because if you use it as a learning tool, it's going to teach you a lot of bad habits.
The ad-server gets anything from 0 to ~20 inserts per second across some 200 sites, and depending on the client policy, is cleared daily,weekly,monthly or yearly of that clients data.
Vacuum after you purge this data and you're done.
Now, my understanding of the vacuum command was that it effectively took the DB offline
Not true since 7.3, which has been out a while.
my understanding of 'auto-vacuum' was that it would negate that effective downtime. It appears that that is not the case.
Auto-vacuum attempts to automatically determine the tables and frequency that need to be vacuumed. It basically saves you from having to create a cron job or make it part of your standard, daily todos. Having said that, since 7.3 (we're talking 7.4 now), you have been able to vaccum your tables without interferring with production. The auto-vacuum feature is just icing on the cake.
MySQL copes with this quite happily. I was simply investigating whether postgres would cope equally happily... more strings to the bow etc...
PostgreSQL happy copes with that much data in a production environment, and far, far, far more.
I would simply say this. Either you didn't look very hard or you can't find an online book store.
There are several good books in print for PostgreSQL. There is a ton of documentation available. Calling, writing, defining and using functions are fairly well documented. In fact, so is creating your own data types. Furthermore, anything that is confusing to you, can easily ask on one of many news groups and/or mailing lists. People are more than happy to help. Seems you shooting them without having even tried first. Ouch.
For what I do, my access is via c/c++, php or visual basic, not psql.
For C++, I can't recommend libpqxx enough. The guy is a C++ guru and loves to make the library better, faster, stronger. Not being a php guy, I can't really address that, however, I hear it's a no brainer. As for VB, well, you're going to be using ODBC and PostgreSQL has fairly good ODBC facilities. IIRC, you can even get commercially supported drivers.
Almost all the Postgresql documentation seems to be assuming that you are running psql.
Well, of course it does. It's the tool that it can safely assume everyone, on all platforms, has easy access to. If you can do it in psql, you can do it with any other tool. Psql is just a DB connection with some command line editing and lots of nice extras. It's the equivilent of what pretty much every other RDBMs offers. Not really sure what the confusion or issue is here.
All an end user knows is the user interface: either a web browser interface or a Windoze GUI.
Not really sure why you'd worry about pgsql then. Having said that, pgsql can easily be used to create web interface result sets. It works well for CGI. Don't want to use CGI? Well, use one of many of the available language libraries to extract the data you need. You'll find language bindings for just about anything: C, C++, perl, python, tcl, OBDC, and many, many more that I've left out.
I think the query planner and the connection queue will give a database a much better idea of what needs to be cached, the OS will simply never be able to understand the database's needs at teh same level.
And chances are, the DB will make the wrong choice. This is why most people prefer to defer to the OS so that the overall system still benefits rather than just the DB reaching a breakeven point.
Remember: o The OS must still have a FS cache
Creating a DB cache which is redundant of the FS cache, wastes memory and I/O -- This is counter to the performance goals o Cache trends are easy so long as there is only one query at a time. Add in multiple queries where the result sets are larger than what can fit into memory, the DB cache manager is almost certain to be wrong.
Perform a query which results in a sequential scan of a very large table. Perform a scan which randomly pulls data from the table's index. Performa a scan which randomly pulls data from the table. Perform a query, resulting in sequential scan, on another very large table where the results will not fit into memory. Now, add in various misc. queries against the above tables and a dozen others. What data should still be in cache? Ah, gut says, data from the large table queries. But wait. Those two queries are only performed once per day. o On systems where the DB would attempt to manage the cache, admins tend to over commit memory resources to the DB, thus causing shortages for the rest of the system. This results in wasted I/O and CPU cycles.
This is just touching the very tip. Simple fact is, the DB cache manager is almost certain to be wrong. The FS drivers are already pretty good at guestimating data access and caching as needed. Granted, there are some corner cases where the DB can cache better. But generally speaking, most of these are covered on any modern DBMS. As such, trying to write a cache manager which will probably do as well as the FS/drive/VM cache managers, is nothing but a waste of time and energy. Then, it has to be maintained.
So, it's safe to say that your original argument is completely false.
I'm amazed that you're giving push-back on something that is common sense.
Some procedure is a best practice only if you intend to achieve the effect for which the practice is accepted to be best. Right?
Right...and if you used a "best practice" on something that didn't apply, it would no longer be "best practice", now would it. Thusly, my statement is still intact.
In other words, using a hamer is a best practice for driving a nail into a wall. Using a hamer is not a best practice if you intend to screw a bolt into that wall.
Exactly. Using a hammer on a screw makes for a low quality screw driver. Someone (the user) may be happy with the situation but it doesn't change the fact that any carpenter is going to look at you like a dolt and immediately realize that a screwdriver is the "best practice". Seems you made my point. Thank you.
But this means that if a user is okay with something, it must be of high quality! For if it's okay, than it must fit the purpose that user intends it for, right?
No. It absolutely does not mean that. There is an old saying and it goes something like this. Ignorance is bliss. Running with the above example, if a user didn't even know about something called a screwdriver, they might be perfectly happy with their hammer. Now granted, it might be a mighty-fine, high quality hammer, but it's still a low quality screwdriver.
So repeat this mantra: Quality is in the eye of the beholder (and keep it in mind if you're developing software - the only thing that determines whether the software is any good is whether it fits the purpose the user intends it for)
Well, you can repeat that all you want, it still just plain wrong. Just because a user is happy with a tool, does not mean it's a quality tool. So, say after me, "Ignorance is bliss". Something tells me you'll be happy after you repeat that a couple hundred times.;)
I'm fully aware of the fact that/. is running MySQL. As most/.'ers are well aware of, MySQL is the reason why./ often has serious down time. Furthermore, MySQL has been unable to scale for years and years now. To work around the many, many short commings and failings of MySQL, most pages are statically rendered and even then,/. still suffers.
If you want to point a finger at/. and say, "see", understand that you made the case that MySQL is a joke for any serious (scalable) website. In fact, SF used to run MySQL and they had to port to PostgreSQL to be able to function at all. They out grew MySQL really quickly. They were thrilled with PostgreSQL. The only reason they finally went to DB2 is because the dot com boom was over and they needed cash. IBM offered a sweetheart deal with DB2 and some advertising cash.
What do these stories tell you? It tells you that MySQL is a joke and that PostgreSQL scales and performs up there with the big boys.
Historically, Innodb didn't exist until "recently".
Actually, Innodb has existed for a while now. Most anyone that thinks of MySQL automatically consider Innodb to be part of the mix. MySQL is a play toy without. The down side is, MySQL performs even worse with it. Which in turn, further clouds the issue in most MySQL user's minds.
There are generally two camps that pop up every time I see MySQL brought up. Those that know and understand RDBM systems and those that use MySQL.
Clearly you've not had to use raw disks for anything of size or anything that matters. They are a pain. They are problematic to backup. They are problematic to restore. And frankly, the speed differences just are not there to justify the headaches. Last I heard, you get maybe 2-5% performance boost...and that's a BIG maybe.
Very, very, very, very, very few people really need raw disk access for their database needs. Chances are, if you're using MySQL, you don't need to be using it either. You could easily use PostgreSQL and get the same performance using a FS, if not far, far better.
But Mysql is designed for speed and average use on websites
The problem with that statement is, MySQL has historically performed very poorly even for mostly read-only sites where any level of concurrency is required. Historically, MySQL rocks with one or two users and starts to take a bath as you begin to add more concurrency. If you have to mix read/write activity, then MySQL is absolutely horrid. This is why, again historically, when people test MySQL using their simple, single user tests, MySQL shines. When used in production, MySQL historically stinks like rotten eggs. PostgreSQL, on the other hand, scales rather well. Furthermore, the last two or three major releases has further increased its scalability.
Now then, throw a complex query at MySQL, it will smell like a dozen rotten eggs on a hot summer day.
Long story short, I'm constantly amazed at why people would defend such lessor product. Is having to be right so important? Why can't people just acknowledge that PostgreSQL is the better product and move on.
Quality is defined by best practices and standards as accepted by the peers of it's creaters. Something can be of poor quality and still be okay for that user, but it's still low quality.
Not so. The article implies that the problem comes from bad admins, and systems that were infected with one of the recent MS worms. Seems either the worm or the cure enables the guest account. Thus the point of the article. If you were infected, besure to double check that the guest account is still disabled.
This begs the question: Is it better for security researchers to avoid publicly criticizing e-voting flaws? Is public faith in the system more important than overall system security?"
Of course not. If they fix security, faith will follow. It really is that simple. This is like leaving your front door wide open while you go on holiday and then being upset when people worry that their house will be robbed while they are gone. Secure the door well and people will feel better. It really is that simple.
In a nut shell, it's Linda Lamone that's doing a great disservice to democracy, technology, and the people that elected and/or hired her to do what's best for the people in her distirct(s). I can't think of anything more un-American that ensuring democracy is easily manipulated and faith in the results is shaken. She needs to be beaten with a stick and replaced. She is either incompetent or actively wants a mechanism to minipulate election results.
First, let me say thank you for sharing that detailed write up. That's very considerate.
Funny - your answers rated 2 each;) Go, US, go!;)
Well, glad we're still laughing here!:) I honestly did not mean to make it sound like a raw-raw-go-US thing.
Not a problem, yes, it's exactly "one of the best", but not "the best" - this is my point.
Agreed. The apache is not "the best", however, it is a dang fine instrument. Then again, I might be baised...my brother is a Longbow pilot and is stationed in Iraq right now.;)
Very hard to tell who is the best - helicopters (and almost any other comparision objects) outperforms each other by different parameters.
Agreed.
The helicopter has a number of unique characteristics including single seat to increase combat and flight characteristics and reduce operational costs.
Most studies show that it does reduce operational costs but greatly reduces combat effectiness. The reason being, on a modern battlefield, most cockpits these days quickly overwork and overload a single pilot. The result is greatly increased chance of human error and/or big reduction in combat effectiviness. So, while it's cost cutting measure, it's not generally considered a combat plus.
The fully armored pilot's cabin can withstand 23-mm gunfire
That's actually very impressive. I'd have to look and see what the Apache is rated for, but I'm fiarly sure it's not that good. Just the same, two Apache's in Afganistan where hit with RPG's, one on the front of the cockpit (blew flir system off) and the other took a direct hit on the transmission. Both flew home. Clearly pretty rugged. No pilots were injured.
The Zvezda K-37-800 pilot ejection system functions at any altitude, and enables a successful ejection at low altitude and maximum speed.
This is something I spoken about with my brother. Ya, it would be nice to have one, just the same, they are rarely needed in copters like the Apache. The reason being, just about anything that's going to bring you out of the air is probably going to kill you. Those that don't, you can almost always autorotate down. This leaves a tiny, tiny, margin supporting the, "it would be nice", but generally not very useful in real combat. Add in the fact that most attack copters operate 20-150 feet off the ground, it's a big, big "if" that they can even hit the ejection system before they hit the ground in the tiny margin that's left. Still, I have to give the brownie button to the Ka.
It's most remarkable feature is a remote targeting system with a capability to provide for a sudden deadly attack from a distance that rules out direct visual contact with the target. The firing computer will turn the aircraft to keep the gun on target. It is equipped with downlink to provide information from the battlefield. The targeting and control system and weaponry enable accurate target engagement at ranges of up to 10km.
Yep, the Apache Longbow does all of that. The targeting computer even allows for indirect fire, bvr, targeting with it's 20mm cannon. In fact, the entire weapon system is designed to allow bvr or over the hill engagment for it's cannon and hellfire missiles. IIRC, a hellfire can be fired up to ~30' off from the target and still be ensured a hit. That greatly increases battlefield confusion along with survivability.
Also, only a single Apache need expose it self (and then, only the dome on top) to acquire, prioritize, and dispatch targets to all (Generally 5-7) Apache Longbows that's flying with it. To boot, it only has to be exposed for something like 15-20 seconds for a full 360' battlefield/target view. From there, all targets can be engaged and killed without exposing themselves again.
Oh, and btw, both major Apache variants can fire the sidewinder missile. It's just that the Air Force threw a fit abou
Slashdot Mirror
It's a bit like prohibition basically -- everyone at the time thought it was a good idea, but no one lived up to it, and it turned out to be mind bogglingly stupid. We were best rid of it.
I'm not sure I buy into that statement. Prohibition ended because it created an even worse environment. It created far more criminals who broke far worse laws. Murder, extortion, racketeering, rising in lessor crimes and general violence. All with a reduction in tax income (IIRC). Worse, there were a number of cases where cops and judges were being paid of to allow violations to get off with minimal pain.
Until you can prove that p2p is causing murder, racketerring, people being beat up on the streets, or corrupt judges and police, it's fairly hard to even begin to compare the two.
...a cluster of these!!! ;)
Ya, I followed that thread too. I thought it was fairly interesting myself. Seems the kernel runs out of kernel memory to handle the kernel-like printf statement. The fix is to convert it to an iterative approach whereby, many smaller chucks of memory simple get reused. Appears the infrastructure was already in place from another part of the kernel. So, seems it will be a fairly quick fix for them.
I knew it wasn't a joke (or certainly hoped not) and immediately thought, WOW! Serious scalability!
Tons and tons of work has gone into 2.6 to make it fully NUMA aware and scalable. Last I heard, there were still some minor memory allocation node biases left in the scheduler, however, those are actively being worked on. Furthermore, they were considered corner cases and not general NUMA processing problem domains.
IIRC, one or more the developers has a 128 (or larger, I forget) CPU NUMA system that 2.6 periodically gets tested against. Many smaller NUMA systems are commonly used by several others. It seems that many, but not all of the NUMA optimizations, also help SMP systems as well. As such, the developers have not been shy about embracing it. When the O(1) scheduler was writen, it was a very short period of time before they started adding HT and NUMA optimizations to it.
What, you mean the rating system they used was completely worthless? What? You mean that Fox destroyed their own show? What? You mean that in spite of Fox being incompetent, they've had absolutely wonderful shows? What? You mean Futurama? Family Guy? didn't suck?
The executives at Fox are brain dead.
P.S. For the record, I tried watching that horrible show called Firefly. On the rare occation that I was able to watch it, in spite of Fox's best efforts, I must say, the show was horrible! I'm sorry, but cowboys in space is stupid. Seems I stand corrected. Fox actually did something right! Go figure.
I know some people went crazy over that show...why? Help me out here? Everything I saw was bad writing, bad stories, and hoakie anachronisms in space. I really enjoy good sci-fi. And generally, I can watch just about anything. Will someone please fill me in on what they thought was good about that horrible show? Please? I feel like I'm missing something....but my brain says I'm not.
Again, someone gets it!
Good for you!
I tip my hat!
Agreed! Someone gets it!
Good for you!
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.
If performance is lacking that much, I would guess that it means you have some SQL that needs to be rewritten or made more "postgresql-ized". The optimizer makes some assumptions here and there and without changing SQL to what PostgreSQL likes, it can make bad plans. Any engine can. Having said that, any time you port SQL to another engine, you're going to have to expect to make SQL changes. Comparing optimized SQL on one platform with unoptimized results on another is rediculas. Which is, needless to say, pretty much what you're spelling out here in your results.
[...]but I just couldn't get reasonable performance out of the database without doing some serious SQL-rewriting
Understood. Some RDBMS actually have their optimizer rewrite queries, giving you the impression that it's good SQL when it should really be expressed in some other form. In other words, you'll probably have to change the query a little bit to optimize it for PostgreSQL.
putting optimizer hints into the queries is just too much
That's a good thing, considering, PostgreSQL doesn't support hints, nor do they plan to.
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
In the vast, vast majority of these cases, it's because people cast something to a differing type than what is indexed and rightly so, the optimizer ignores it. Generally speaking, simply changing to the proper or more sane cast corrects this issue. After doing so, performance generally rocks.
Databases with simple queries where results are not needed instantly would do well with PostgreSQL.
Actual real-world results and very, very large databases disagree with your assessment. MySQL's optimizer is pethetic. As bad as you seem to dislike PostgreSQL's, it's lightyears ahead of MySQL's, especially for complex queries.
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.
This is called, knowing your dependencies and bothering to test before it goes into production.
debugging a stored procedure or trigger is not easy.
Actually, stored procedures tend to be fairly easy to debug if you approach them correctly. Triggers, on the other hand, can be somewhat tricky. Then again, triggers should always be used sparingly.
people tend to forget about triggers and stored procedures; they're hidden logic that can cause no end of problems.
Sounds like serious abuse/misuse of the facilities. Used correctly, they are mana from heaven. It's a great place to enforce business rules and centralize common business logic. Done properly, they will save tons in application code, debugging and ease applicatoin migration issues. Of course, the problem comes when you need to migrate to another database.
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.
Yes, they are pretty much a vendor lock-in. That being said, how often are you changing database backends? Compared to how often clients tend to change, it's usually more than a fair trade.
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 deve
You were modded down because there are many incompetent people that get moderator points and have yet to figure out the proper and responsible way to use those points. With luck, metamoderation will help correct what was so obviously done incorrectly.
You've been modded as a troll because your position is untennable.
Regardless, that would make the moderator an idiot because that's not his role. His role is to help make interesting stuff float to the top. Likewise, make crap sink to the bottom. In this case, even though I disagree with the posting, it should of been left as is (rightly so) or mod'd interesting, because that's what it is. A troll, it certainly is not.
Just because a moderator disagrees with a posting is NOT cause for it to be mod'd as "troll" or "overrated". I'm constantly finding that when I meta-mod, there are tons of idiot moderators that I'm having to come behind and correct. In fact, I'd say, maybe 1 out of 4, or maybe 1 out of 6 meta-mods (series of modding mods) that I do, do I find that moderators have actually done their job correctly. The fact that you've answered as you have might indicate that you should pass on your next chance to moderate until you've read the moderation rules. Hint, hint.
While I don't agree with the comments, it clearly is not a "troll". I would of rated it interesting. I would, however, rate the moderator as "idiot" or "incompetent".
Like it or not moderators, your job is not to mod down things you disagree with. You job to to find and moderate interesting tidbits, opinions, and facts so that the population at large can better enjoy the more interestings stuff.
Can you give some benchmarks of when Innodb would be slower than Postgresql?
;", and have more than a couple of rows worth of data, or multiple indexes (multiple data paths) a query planner is probably going to be important to you. Furthermore, PostgreSQL's planner is highly tunable and the query plans are easily obtainable (for review, validation and optimization). Furthermore, the query planner even supports a genetic algorithm to aid optimizing data path access in even the most bizzar of production query requirements (see GA link for more information). To boot, the planner fully understands virtual I/O, physical I/O, indexes, various join types and algorithms, and is able to grok very complex queries fairly well. This is not to say it's perfect. It's not. Just the same, this feature alone is head and shoulders above MySQL. This is why tables joins is often an problem for MySQL's performance.
Actually, the problem isn't so much that you can point a finger at Innodb. Having said that, Innodb is slower than straight up MySQL tables. Aside from that, you need to remember that it's the overall design that's making the difference. PostgreSQL implements a scheme called versioning which greatly reduces the amount of table locking required (see mvcc for more information and explanation). Interestingly enough, this is very simular to what Oracle uses. Beyond that, PostgreSQL has an excellent caching mechanism which greatly helps reduce disk I/O.
No matter how fast you can access your tables, if you can't effectively determine a plan to access your tables, you're going to be slow. PostgreSQL has an excellent optimizing query planner. MySQL has nothing like it. This means that if you use queries which are more than, "select * from foo
Is the scalability jokes you refered to, uses innodb?
Please keep in mind that I was being overly cynical. Just the same, most performance benchmarks which attempt to put MySQL in good light, attempt to minimize the use of Inno tables. The reason being, inno tables impose a performance hit because of the extra features (transactions, etc). Because of this, tests often attempt to NOT use innodb tables unless the test is specifically in place to validate transactional support and associated features. This means, that MySQL almost always looks wicked fast unless data validity is important to you. If it is, you take a performance hit. In both cases, hope you don't have to read and write data at the same time in the same tables. If you do, the table locking will shoot you in the foot. This, for both native and inno tables.
Can you give some example of what makes Postresql more scalable, beside being more sql compliant or closer to a "read rdbms"?
Well, being more SQL compliant really doesn't make it scalable. It's nice and all, but it doesn't do anything for scalability. It does, however, allow you to leverage generalize SQL expertise much more easily. Which, in turn, can translate to better performance.
Let's talk a little bit about performance and scalability. Performance is generally measured in the latency of asking for a result and the time it takes to get a *complete* result back. I stress complete here because somes tests improperly measure. In some cases, some RDBMS will attempt to start returning result sets VERY quickly in order to give the illusion that it's latency is very low, however, the total time for the operation is much, much higher. Thusly, we'll say time for a *complete* result set. In most cases, a partial result set is worthless or out of context until all of the data is available for analysis.
Scalability, on the other hand, is the ability to continue to delivery timely (low latency) results as the load increases. For a typical DB, load generally means inserts, updates and deletes, however, specific workload
Neither PosgreSQL or mySQL are full, complete, and utterly perfect implemtations of a database. Neither is Oracle, BTW.
I completely agree!
Back then, mySQL couldn't be beat for handling read-only
Actually, at the time, most real benchmarks proved that to be false. MySQL and several others performed some benchmarks, using the current version of MySQL and outdated versions of PostgreSQL. Futhermore, most tests were a single query against a database. The result, MySQL was wicked fast. This was done because most web guys didn't know anything about DB's and so they did what they thought was a good test. They tested what they knew. The tested a single query with a single user and it was, indeed fast. In fact, faster than PostgreSQL. The problem was, few people tested concurrent access (typical of web sites). Those that did found that the speed advantage of MySQL very quickly disappeared and PostgreSQL shinned wonderfully. To date, MySQL's performance myths still persist. The simple fact is, MySQL has never been a performing beast, as most people think. Simple fact is, even all those years ago, PostgreSQL almost always out performs and out scales MySQL at all but the most basic of SQL tasks. And so, it became lore that MySQL is wicked fast and that PostgreSQL is wicked slow, but feature rich.
Since those days, PostgreSQL has gotten much, much faster and now scales much, much better. MySQL, I believe has worked some on it's scalability, however, the last thing I saw, it's still far behind PostgreSQL for all but the most basic of SQL tasks.
That basis of comparison is no longer true.
The generally available comparisions were never true. Generally speaking, everything that MySQL ever put into print on benchmarks were lies or willful efforts to mislead and misrepresent the truth. Simple fact is, MySQL did everything they could to prevent being compared toe to toe with a modern PostgreSQL. It doesn't take a rocket scientist to figure out why that might be.
Day 1 you have a need, day 2 you actually research available solutions, and day 3 you declare a "winner" and it is forevermore cast in stone as the "one true solution". The fact masses of people tend to go thorugh the same process at basically the same time doesn't help. Thus the broad noise that mySQL is "the Answer(tm)".
Couldn't agree more. Worse, more often then not, the people picking the RDMBS solution are completely unqualified to make such a solution. Then, the legacy "winner" finds its self as the solution over and over again.
Anyway, postreSQL has always sought to compete in the full function space. Oracle was/is a much better "comparison" to postgreSQL than mySQL.
Absolutely correct!
Bottom line, if you invested in learning and implementing mySQL, and it is still working for you, then there is absolurely no need to be concerned with postgreSQL yet.
I'm not sure I buy 100% into that statement. Just the same, I think it rings true enough. I generally tell people, if you wouldn't use an Access DB for your solution, then you shouldn't use MySQL. The funny thing is, Access actually has a richer set of features than even MySQL does. I think the Access comparision comment still holds true today.
Yes, evaluate both, but don't assume mySQL or postgreSQL is "better" based on what you hear.
I strongly believe in "best tool for the job". As such, it is true that PostgreSQL may not be the best tool. Even the PostgreSQL developers will tell you that. Just the same, I often find that MySQL is rarely the best tool for the job. That's not to say that it's not a good SQL introduction and *maybe* as a learning tool, it might have value. The maybe is there because if you use it as a learning tool, it's going to teach you a lot of bad habits.
The ad-server gets anything from 0 to ~20 inserts per second across some 200 sites, and depending on the client policy, is cleared daily,weekly,monthly or yearly of that clients data.
Vacuum after you purge this data and you're done.
Now, my understanding of the vacuum command was that it effectively took the DB offline
Not true since 7.3, which has been out a while.
my understanding of 'auto-vacuum' was that it would negate that effective downtime. It appears that that is not the case.
Auto-vacuum attempts to automatically determine the tables and frequency that need to be vacuumed. It basically saves you from having to create a cron job or make it part of your standard, daily todos. Having said that, since 7.3 (we're talking 7.4 now), you have been able to vaccum your tables without interferring with production. The auto-vacuum feature is just icing on the cake.
MySQL copes with this quite happily. I was simply investigating whether postgres would cope equally happily... more strings to the bow etc...
PostgreSQL happy copes with that much data in a production environment, and far, far, far more.
I would simply say this. Either you didn't look very hard or you can't find an online book store.
There are several good books in print for PostgreSQL. There is a ton of documentation available. Calling, writing, defining and using functions are fairly well documented. In fact, so is creating your own data types. Furthermore, anything that is confusing to you, can easily ask on one of many news groups and/or mailing lists. People are more than happy to help. Seems you shooting them without having even tried first. Ouch.
For what I do, my access is via c/c++, php or visual basic, not psql.
For C++, I can't recommend libpqxx enough. The guy is a C++ guru and loves to make the library better, faster, stronger. Not being a php guy, I can't really address that, however, I hear it's a no brainer. As for VB, well, you're going to be using ODBC and PostgreSQL has fairly good ODBC facilities. IIRC, you can even get commercially supported drivers.
Almost all the Postgresql documentation seems to be assuming that you are running psql.
Well, of course it does. It's the tool that it can safely assume everyone, on all platforms, has easy access to. If you can do it in psql, you can do it with any other tool. Psql is just a DB connection with some command line editing and lots of nice extras. It's the equivilent of what pretty much every other RDBMs offers. Not really sure what the confusion or issue is here.
All an end user knows is the user interface: either a web browser interface or a Windoze GUI.
Not really sure why you'd worry about pgsql then. Having said that, pgsql can easily be used to create web interface result sets. It works well for CGI. Don't want to use CGI? Well, use one of many of the available language libraries to extract the data you need. You'll find language bindings for just about anything: C, C++, perl, python, tcl, OBDC, and many, many more that I've left out.
I think the query planner and the connection queue will give a database a much better idea of what needs to be cached, the OS will simply never be able to understand the database's needs at teh same level.
And chances are, the DB will make the wrong choice. This is why most people prefer to defer to the OS so that the overall system still benefits rather than just the DB reaching a breakeven point.
Remember:
o The OS must still have a FS cache
Creating a DB cache which is redundant of the FS cache, wastes memory and I/O -- This is counter to the performance goals
o Cache trends are easy so long as there is only one query at a time. Add in multiple queries where the result sets are larger than what can fit into memory, the DB cache manager is almost certain to be wrong.
Perform a query which results in a sequential scan of a very large table. Perform a scan which randomly pulls data from the table's index. Performa a scan which randomly pulls data from the table. Perform a query, resulting in sequential scan, on another very large table where the results will not fit into memory. Now, add in various misc. queries against the above tables and a dozen others. What data should still be in cache? Ah, gut says, data from the large table queries. But wait. Those two queries are only performed once per day.
o On systems where the DB would attempt to manage the cache, admins tend to over commit memory resources to the DB, thus causing shortages for the rest of the system. This results in wasted I/O and CPU cycles.
This is just touching the very tip. Simple fact is, the DB cache manager is almost certain to be wrong. The FS drivers are already pretty good at guestimating data access and caching as needed. Granted, there are some corner cases where the DB can cache better. But generally speaking, most of these are covered on any modern DBMS. As such, trying to write a cache manager which will probably do as well as the FS/drive/VM cache managers, is nothing but a waste of time and energy. Then, it has to be maintained.
So, it's safe to say that your original argument is completely false.
This is silly.
;)
I'm amazed that you're giving push-back on something that is common sense.
Some procedure is a best practice only if you intend to achieve the effect for which the practice is accepted to be best. Right?
Right...and if you used a "best practice" on something that didn't apply, it would no longer be "best practice", now would it. Thusly, my statement is still intact.
In other words, using a hamer is a best practice for driving a nail into a wall. Using a hamer is not a best practice if you intend to screw a bolt into that wall.
Exactly. Using a hammer on a screw makes for a low quality screw driver. Someone (the user) may be happy with the situation but it doesn't change the fact that any carpenter is going to look at you like a dolt and immediately realize that a screwdriver is the "best practice". Seems you made my point. Thank you.
But this means that if a user is okay with something, it must be of high quality! For if it's okay, than it must fit the purpose that user intends it for, right?
No. It absolutely does not mean that. There is an old saying and it goes something like this. Ignorance is bliss. Running with the above example, if a user didn't even know about something called a screwdriver, they might be perfectly happy with their hammer. Now granted, it might be a mighty-fine, high quality hammer, but it's still a low quality screwdriver.
So repeat this mantra: Quality is in the eye of the beholder (and keep it in mind if you're developing software - the only thing that determines whether the software is any good is whether it fits the purpose the user intends it for)
Well, you can repeat that all you want, it still just plain wrong. Just because a user is happy with a tool, does not mean it's a quality tool. So, say after me, "Ignorance is bliss". Something tells me you'll be happy after you repeat that a couple hundred times.
I'm fully aware of the fact that /. is running MySQL. As most /.'ers are well aware of, MySQL is the reason why ./ often has serious down time. Furthermore, MySQL has been unable to scale for years and years now. To work around the many, many short commings and failings of MySQL, most pages are statically rendered and even then, /. still suffers.
/. and say, "see", understand that you made the case that MySQL is a joke for any serious (scalable) website. In fact, SF used to run MySQL and they had to port to PostgreSQL to be able to function at all. They out grew MySQL really quickly. They were thrilled with PostgreSQL. The only reason they finally went to DB2 is because the dot com boom was over and they needed cash. IBM offered a sweetheart deal with DB2 and some advertising cash.
If you want to point a finger at
What do these stories tell you? It tells you that MySQL is a joke and that PostgreSQL scales and performs up there with the big boys.
Historically, Innodb didn't exist until "recently".
Actually, Innodb has existed for a while now. Most anyone that thinks of MySQL automatically consider Innodb to be part of the mix. MySQL is a play toy without. The down side is, MySQL performs even worse with it. Which in turn, further clouds the issue in most MySQL user's minds.
There are generally two camps that pop up every time I see MySQL brought up. Those that know and understand RDBM systems and those that use MySQL.
Most people run a cron job which vacuumed as needed. No fuss. Easily done. Didn't disturb production at all.
Clearly you've not had to use raw disks for anything of size or anything that matters. They are a pain. They are problematic to backup. They are problematic to restore. And frankly, the speed differences just are not there to justify the headaches. Last I heard, you get maybe 2-5% performance boost...and that's a BIG maybe.
Very, very, very, very, very few people really need raw disk access for their database needs. Chances are, if you're using MySQL, you don't need to be using it either. You could easily use PostgreSQL and get the same performance using a FS, if not far, far better.
But Mysql is designed for speed and average use on websites
The problem with that statement is, MySQL has historically performed very poorly even for mostly read-only sites where any level of concurrency is required. Historically, MySQL rocks with one or two users and starts to take a bath as you begin to add more concurrency. If you have to mix read/write activity, then MySQL is absolutely horrid. This is why, again historically, when people test MySQL using their simple, single user tests, MySQL shines. When used in production, MySQL historically stinks like rotten eggs. PostgreSQL, on the other hand, scales rather well. Furthermore, the last two or three major releases has further increased its scalability.
Now then, throw a complex query at MySQL, it will smell like a dozen rotten eggs on a hot summer day.
Long story short, I'm constantly amazed at why people would defend such lessor product. Is having to be right so important? Why can't people just acknowledge that PostgreSQL is the better product and move on.
Quality is defined by best practices and standards as accepted by the peers of it's creaters. Something can be of poor quality and still be okay for that user, but it's still low quality.
Not so. The article implies that the problem comes from bad admins, and systems that were infected with one of the recent MS worms. Seems either the worm or the cure enables the guest account. Thus the point of the article. If you were infected, besure to double check that the guest account is still disabled.
This begs the question: Is it better for security researchers to avoid publicly criticizing e-voting flaws? Is public faith in the system more important than overall system security?"
Of course not. If they fix security, faith will follow. It really is that simple. This is like leaving your front door wide open while you go on holiday and then being upset when people worry that their house will be robbed while they are gone. Secure the door well and people will feel better. It really is that simple.
In a nut shell, it's Linda Lamone that's doing a great disservice to democracy, technology, and the people that elected and/or hired her to do what's best for the people in her distirct(s). I can't think of anything more un-American that ensuring democracy is easily manipulated and faith in the results is shaken. She needs to be beaten with a stick and replaced. She is either incompetent or actively wants a mechanism to minipulate election results.
First, let me say thank you for sharing that detailed write up. That's very considerate.
;) Go, US, go! ;)
:) I honestly did not mean to make it sound like a raw-raw-go-US thing.
;)
Funny - your answers rated 2 each
Well, glad we're still laughing here!
Not a problem, yes, it's exactly "one of the best", but not "the best" - this is my point.
Agreed. The apache is not "the best", however, it is a dang fine instrument. Then again, I might be baised...my brother is a Longbow pilot and is stationed in Iraq right now.
Very hard to tell who is the best - helicopters (and almost any other comparision objects) outperforms each other by different parameters.
Agreed.
The helicopter has a number of unique characteristics including single seat to increase combat and flight characteristics and reduce operational costs.
Most studies show that it does reduce operational costs but greatly reduces combat effectiness. The reason being, on a modern battlefield, most cockpits these days quickly overwork and overload a single pilot. The result is greatly increased chance of human error and/or big reduction in combat effectiviness. So, while it's cost cutting measure, it's not generally considered a combat plus.
The fully armored pilot's cabin can withstand 23-mm gunfire
That's actually very impressive. I'd have to look and see what the Apache is rated for, but I'm fiarly sure it's not that good. Just the same, two Apache's in Afganistan where hit with RPG's, one on the front of the cockpit (blew flir system off) and the other took a direct hit on the transmission. Both flew home. Clearly pretty rugged. No pilots were injured.
The Zvezda K-37-800 pilot ejection system functions at any altitude, and enables a successful ejection at low altitude and maximum speed.
This is something I spoken about with my brother. Ya, it would be nice to have one, just the same, they are rarely needed in copters like the Apache. The reason being, just about anything that's going to bring you out of the air is probably going to kill you. Those that don't, you can almost always autorotate down. This leaves a tiny, tiny, margin supporting the, "it would be nice", but generally not very useful in real combat. Add in the fact that most attack copters operate 20-150 feet off the ground, it's a big, big "if" that they can even hit the ejection system before they hit the ground in the tiny margin that's left. Still, I have to give the brownie button to the Ka.
It's most remarkable feature is a remote targeting system with a capability to provide for a sudden deadly attack from a distance that rules out direct visual contact with the target. The firing computer will turn the aircraft to keep the gun on target. It is equipped with downlink to provide information from the battlefield. The targeting and control system and weaponry enable accurate target engagement at ranges of up to 10km.
Yep, the Apache Longbow does all of that. The targeting computer even allows for indirect fire, bvr, targeting with it's 20mm cannon. In fact, the entire weapon system is designed to allow bvr or over the hill engagment for it's cannon and hellfire missiles. IIRC, a hellfire can be fired up to ~30' off from the target and still be ensured a hit. That greatly increases battlefield confusion along with survivability.
Also, only a single Apache need expose it self (and then, only the dome on top) to acquire, prioritize, and dispatch targets to all (Generally 5-7) Apache Longbows that's flying with it. To boot, it only has to be exposed for something like 15-20 seconds for a full 360' battlefield/target view. From there, all targets can be engaged and killed without exposing themselves again.
Oh, and btw, both major Apache variants can fire the sidewinder missile. It's just that the Air Force threw a fit abou