I swear you environmentalists are crazy. What you are proposing would be like you go to the doctor, you have a slight fever, he does a single test that is incorrect 50% of the time, and then recommends you spend $1,000,000 to get a liver transplant, kidney transplants, heart transplant, bone marrow transplant, and just for fun, chemo cause it might be cancer too. Or, maybe you should just take a Tylenol and call him in the morning? But no, if we wait for just 10 minutes and think about it, and try to get a better diagnosis, well if the first diagnosis is right then you'll be dead, so better just go with that!
Um, no. It's more like you go to the doctor and he says there is a 90% chance you are going to have a heart attack, it's mostly just a question of when. Of course, you can always wait and see if you develop chest pains first, or maybe just get lucky.
Or you could cut back on the Big Macs that you started eating for breakfast AND lunch a decade ago, because it certainly couldn't hurt.
But hey, you like your Big Macs and you might not have a heart attack.
That is why the models don't work. Sure they are complicated and very advanced, but they don't take into account the increased carbon sequestration that plants automatically do when presented with higher CO2 in the atmosphere (as he states in the article). And they also aren't very good at dealing with random things like clouds, dust, or other non-fluid dynamics type phenomena.
Really? None of the climate models have ever accounted for plants absorbing carbon? Do you know anything about what is or isn't in the models, or are you just pushing your agenda? You are right about one thing, it's not a purely meteorological problem. I didn't mean to imply that it is.
I love how you just out of hand discredit him because he's not an "expert" in the field. As if thinking rational people can't have a debate about something unless they have a PhD and 20 years experience in a field. How many advanced science degrees does Al Gore have? Years experience studying climate models?
I discredit "thinking, rational people" who try to refute the CONSENSUS of thousands of scientists with PhDs with their own intuition and half-baked theories. I most certainly don't deny anyone's right to debate the issue. But if you can't back up your argument, you might get discredited in the midst of the debate. And I didn't discredit him out of hand - I read his entire argument carefully.
BTW, Al Gore has over 30 years of experience studying climate models - he has been lobbying congress for that long and has consulted heavily with virtually every important scientist in the field over that period of time.
Dyson is a pretty smart guy you know. Physics and all that, I think he might have at least a basic understanding of fluid dynamics, energy transfer, energy storage... yeah pretty much the basics of "climate". I'd certainly listen to and trust him before Al Gore...
I never said Dyson isn't a smart guy. Are you saying I should trust his intuitions because he has a background in physics? Stephen Hawking is pretty smart too, but until he takes the time to make a real serious study of climatology, he's not going to get a call on the subject. And you don't see him spouting his opinions without backing it up.
So go ahead, trust Dyson because he's a smart guy with a degree in physics, and ignore Al Gore who has devoted 30+ years to championing the work of the world's foremost experts in the field. That's pretty much the definition of simply seeking out like-minded opinions.
I'm not an "expert" in the field though so don't listen to me either. Of course the only people you will admit to being "experts" in the field will be people who agree with your world view.
No, I define "experts" as those that are, well, experts in the field. Believe it or not, having silly things like PhDs and decades of research experience are worthy credentials worth paying attention to.
Simple, ideal meterological models???? Really, that's all we have? Just because your local news doesn't predict the weather doesn't mean there is a lot of advanced, complicated, useful meteorology going on.
And no, it's not any less silly than Dennis Miller. Freeman Dyson isn't an expert in the field, and some of his suggestions are a bad joke.
My first heresy says that all the fuss about global warming is grossly exaggerated... There is no doubt that parts of the world are getting warmer, but the warming is not global..
And thus, the more accurate term - "Climate Change", which is just as dangerous as "Global Warming". If you don't know immediately realize the difference, you don't have much business criticizing the science.
Photos, email, word processing, spreadsheets, calendar... all free.
Now, you want to jump completely on the Google OS bandwagon? Rent an online hard drive. They aren't charging you for backup disk space, they're charging you to take the plunge and adopt Google as your operating system.
Granted, it might not be 100% compelling just yet - but this has got to be the end run strategy here. Many people could get by for $10/month or less on these services, and access them with any modern computer. For occasional users, they might not even need a computer of their own any more. As a bonus, they don't have to worry as much about silly things like scanning their own files for viruses and backing them up. In a world where many people spend a minimum of $50/month on a cell phone, this is potentially a solid value.
For a typical Slashdot reader, this is probably less appealing -- "we" aren't Joe Schmo of the OS market and are quite happy piecing something way more powerful solutions ourselves. But Google dreams of Schmo's money...
When you don't care much about transactions/ACID, you can use functions to manipulate external data (which can be in memory, on a separate server, or anything you want), and then use a set-returning function to return the data in the form of a relation (which you can join against, etc). I don't know whether that's a good solution for the general need you're describing, but it seems reasonable that postgres leaves it up you to use already-existing libraries to manage non-ACID data. You could attach it to memcached, or another database engine, or whatever suits your needs. If you want it to behave more like a relation, then you define the rules so that INSERT/UPDATE/DELETE behave like you want them to.
Well yeah, you *could*... or you just change one word of your table definition with MySQL. There are tons of ways to implement simple in-memory storage, including just using memcached directly. But the point is, just because it's not ACID doesn't mean I want to jump through hoops. Forget in-memory stuff, this is exactly why the lightweight MyISAM is nice to have around. I get everything I want from a simple non-ACID storage and I don't have to do anything special to get all the joins / relations I want.
Ok, I see that they are two distinct ways of storing data. I also see that memory tables only store fixed-length records and can't contain BLOB or TEXT data.
Also, keep in mind that PostgreSQL stores it's temporary tables in a similar way. I guess you could consider that a different "storage engine" too, except that it still allows variable-length types.
Well I would hope one wouldn't use memory tables for storing BLOBs =). The point is, as usual, that they have a specific purpose instead of a general one. MySQL has temporary tables as well, and no, they aren't considered a different "storage engine".
But does MySQL even have, for example, a hash aggregate, or does every GROUP BY require a sort? Can it turn an index scan into a bitmap and fetch the tuples in file block order? I don't know a lot about MySQL and the developments it's made recently, but I don't understand how it can use those types of plans if it doesn't use a cost-based planner. You may not need any of these things, but when you do, it can be a huge performance win.
Sorry, I don't know off-hand. What I do know is that MySQL has good performance and a plethora of ways to optimize it. Just like Postgresql. I'm sure there are optimizations possible in each product that are not in the other. Cost-based planners are nice, but they are hardly the only factor in performance. Bottom line, both products can give you pretty impressive performance if you understand your data and how to tweak them.
MySQL may be useful, but I don't consider modularity to be a strong point of MySQL. I really just latched onto the one concept of modularity (which was expressed by the post to which you replied and seconded by your own post). I think that is a big misconception, and I stand by that claim.
That being said, you obviously are aware of the tradeoffs you're making. I am posting because I want to express my opinion to others who might not be aware of the limitations of MySQL's modularity, and the modularity that PostgreSQL does offer.
Fair enough. I can't speak for others, and I have no doubt that MySQL storage engines are misunderstood much of the time. I just disagree that Postgresql is *more* modular rather than just having a different approach - but I doubt we will sway each other on that one.
False on two counts: I never said they weren't useful, I said they weren't modular because they affect the semantics, and are therefore configuration; and I have used MySQL before. If I said something factually incorrect, please correct me.
OK - maybe you didn't say they had no usefullness, but you did start this whole thread by contrasting MyISAM and InnoDB and saying that you didn't "see the point"
I think this is a huge misconception, and completely backwards. MySQL allows you to change storage engines, but the behavior at the semantic level changes. That's the antithesis of modularity: the semantic behavior should remain constant, while the performance changes. If you change both, that's not modularity, that's a new configuration that breaks client applications.
In theory, I see your point. It's not truly modular. In practice, it's handy. MyISAM and InnoDB tables work quite well together.
MySQL is configureware, like PHP. Everything you get is a trade. Want full text indexes (MyISAM)? You have to give up transactions (InnoDB). But the marketing material always just says "Yup, we have full text indexes (MyISAM), SQL compliance (strict mode=on), transactions (InnoDB), large number of apps (strict mode=off)". Of course many of the features are mutually exclusive. When postgresql says it has a feature, it's really there.
Right. And that's a good thing about Postgresql. Now tell me, what do you do in Postgresql when you just want a fast table with no transactional overhead (MyISAM)? Or memory only data? Access to the minimal features can be just as valuable as always having everything available. I could care less which company is more honest in their marketing. I guess the MySQL folks are much better marketers, at the cost of a little transparency.
Seems like the memory engine and NDB are the same thing: http://dev.mysql.com/doc/refman/5.0/en/mysql-clust er-overview.html. That means that your "cluster" is not much of a database, and is totally unacceptable for many applications that require a database. Power off == no more data.
No. The memory (or "heap" engine) is just that - a simple in-memory engine:
http://dev.mysql.com/doc/refman/5.1/en/memory-stor age-engine.html
NDB is the storage engine for MySQL Cluster, and it most certainly is acceptable for applications that need a high-availability clustered solution. The details are way beyond the scope of this post, but it's certainly no joke and is in use in some very high-demand applications (try high-traffic telecommunication apps).
Now compare with PostgreSQL. PostgreSQL has one "storage-engine", but there are many access methods to that storage engine. There's Btree, GiST, and GIN. On top of the access methods, there are also a lot of plans. There's sequential scan, index scan (good for lookups or some sorting needs), bitmap index scan (good for AND/OR with other bitmap index scans, and always orders the I/O in file order), hash join, hash aggregate, merge join, nested loop, group aggregate, etc.
That's nice. Good features. There are also lots of ways to optimize searches in MySQL. BTW, I like Postgresql. Never said I don't.
Look at all those algorithms for accessing the single storage mechanism. It's amazing. MySQL doesn't have all those, and even if it did have the algorithms, it couldn't use them. How would MySQL know when to use a hash join and when to use a merge join? PostgreSQL collects statistics, calculates expected costs, and chooses the best plan based on the given query (called a cost-based planner). MySQL uses a rule-based planner (does it have an index? ok, let's use it then). To PostgreSQL, these two queries are different:
(1) SELECT * FROM parents WHERE number_of_children=2;
(2) SELECT * FROM parents WHERE number_of_children=20;
The stats collector would know that #1 will match many more records than #2. It will probably choose a sequential scan for #1, since it needs to read every page anyway. It will probably choose an index scan for #2. Now, if that's in a subselect, postgresql will know that #1 will return a lot of records, and maybe choose a different
The point IS pick'n'mix as you put it. InnoDB is more valuable because you don't have to use it for every table. When you need a simple, fast table with no transactions, use MyISAM. When I need transactions, InnoDB. Just need some in-memory lookups? Memory table engine. Clustered data? NDB.
There's a lot to be said for having the ability to choose your engine for each table, even if another product has more combined features in one engine. It even opens some interesting replication tricks if you know what you're doing. Run transactions on your InnoDB table, and then replicate it to a read-only MyISAM table on another server, etc - and it works quite painlessly.
Don't get me wrong, if Postgres has something you need and MySQL doesn't, then yeah- the multiple engines all add up to nothing for you. But for a huge variety of projects, they fit the bill quite nicely.
Slashdot Mirror
Simple, ideal meterological models???? Really, that's all we have? Just because your local news doesn't predict the weather doesn't mean there is a lot of advanced, complicated, useful meteorology going on. And no, it's not any less silly than Dennis Miller. Freeman Dyson isn't an expert in the field, and some of his suggestions are a bad joke.
Photos, email, word processing, spreadsheets, calendar... all free.
Now, you want to jump completely on the Google OS bandwagon? Rent an online hard drive. They aren't charging you for backup disk space, they're charging you to take the plunge and adopt Google as your operating system.
Granted, it might not be 100% compelling just yet - but this has got to be the end run strategy here. Many people could get by for $10/month or less on these services, and access them with any modern computer. For occasional users, they might not even need a computer of their own any more. As a bonus, they don't have to worry as much about silly things like scanning their own files for viruses and backing them up. In a world where many people spend a minimum of $50/month on a cell phone, this is potentially a solid value.
For a typical Slashdot reader, this is probably less appealing -- "we" aren't Joe Schmo of the OS market and are quite happy piecing something way more powerful solutions ourselves. But Google dreams of Schmo's money...
Ah, sorry, missed that. Thought it was all the same person. I'm ok with Postgresql advocacy. As long as you aren't pushing MS-SQL.
Well yeah, you *could*... or you just change one word of your table definition with MySQL. There are tons of ways to implement simple in-memory storage, including just using memcached directly. But the point is, just because it's not ACID doesn't mean I want to jump through hoops. Forget in-memory stuff, this is exactly why the lightweight MyISAM is nice to have around. I get everything I want from a simple non-ACID storage and I don't have to do anything special to get all the joins / relations I want.
Well I would hope one wouldn't use memory tables for storing BLOBs =). The point is, as usual, that they have a specific purpose instead of a general one. MySQL has temporary tables as well, and no, they aren't considered a different "storage engine".
Sorry, I don't know off-hand. What I do know is that MySQL has good performance and a plethora of ways to optimize it. Just like Postgresql. I'm sure there are optimizations possible in each product that are not in the other. Cost-based planners are nice, but they are hardly the only factor in performance. Bottom line, both products can give you pretty impressive performance if you understand your data and how to tweak them.
Fair enough. I can't speak for others, and I have no doubt that MySQL storage engines are misunderstood much of the time. I just disagree that Postgresql is *more* modular rather than just having a different approach - but I doubt we will sway each other on that one.
OK - maybe you didn't say they had no usefullness, but you did start this whole thread by contrasting MyISAM and InnoDB and saying that you didn't "see the point"
In theory, I see your point. It's not truly modular. In practice, it's handy. MyISAM and InnoDB tables work quite well together.
Right. And that's a good thing about Postgresql. Now tell me, what do you do in Postgresql when you just want a fast table with no transactional overhead (MyISAM)? Or memory only data? Access to the minimal features can be just as valuable as always having everything available. I could care less which company is more honest in their marketing. I guess the MySQL folks are much better marketers, at the cost of a little transparency.
No. The memory (or "heap" engine) is just that - a simple in-memory engine: http://dev.mysql.com/doc/refman/5.1/en/memory-stor age-engine.html NDB is the storage engine for MySQL Cluster, and it most certainly is acceptable for applications that need a high-availability clustered solution. The details are way beyond the scope of this post, but it's certainly no joke and is in use in some very high-demand applications (try high-traffic telecommunication apps).
That's nice. Good features. There are also lots of ways to optimize searches in MySQL. BTW, I like Postgresql. Never said I don't.
The point IS pick'n'mix as you put it. InnoDB is more valuable because you don't have to use it for every table. When you need a simple, fast table with no transactions, use MyISAM. When I need transactions, InnoDB. Just need some in-memory lookups? Memory table engine. Clustered data? NDB.
There's a lot to be said for having the ability to choose your engine for each table, even if another product has more combined features in one engine. It even opens some interesting replication tricks if you know what you're doing. Run transactions on your InnoDB table, and then replicate it to a read-only MyISAM table on another server, etc - and it works quite painlessly.
Don't get me wrong, if Postgres has something you need and MySQL doesn't, then yeah- the multiple engines all add up to nothing for you. But for a huge variety of projects, they fit the bill quite nicely.