While I can appreciate the notion of "knowledge for knowledge's sake", which is infact how most universities started, that is not reality today. Not all disciplines are equal in economic terms.
Universities are for academic education. Nowadays, universities -- especially in fields like Computer Science -- spend so much time focusing on the immediate economic value of the material that we can't honestly call it an academic institution any more. When professors start talking about "industry" and other similar terms, you know you're in vocational school.
There's nothing wrong with vocational school, they are very useful. However, let's call it what it is. If you are spending more time learning a tool than the abstract concepts behind it, chances are you are in vocational school. The only reason we still call it an academic endeavor is because "vocational school" doesn't sound nearly as impressive.
I think this distinction is important because we need both academic institutions and vocational institutions. But if our academic institutions are being infiltrated by vocational training, then we won't have any academic institutions left.
Guess what - even if you are neither, one of most advanced countries in the world using really open standards IS news, even for you.
I think the excitement of a religious victory drives this story more than the mundane details about what open standards will really mean in this instance.
The simple test to determine whether something is based on ideology or reason is whether different facts could change your opinion.
Hypothetically, if the open standards were a mess, and the implementations were much worse than the current closed systems, and productivity went down as a result of using these open standards, reason might say that now is not the time, and that we should refine the standards before recruiting new users.
If that reasoning did not sway someone, then productivity is not the goal, the goal is the ideology of open standards.
I don't think that's a bad ideology, in fact I share the ideology of open standards. But I recognize that there is some ideology there.
I'm sorry but this is a stupid argument that's been pulled out over and over by people who don't want to take responsabilities.
Read the post you replied to again. His point was perfectly valid: due to special interests, there are high tariffs on sugar, and so it is much more expensive in the US than Brazil, for instance. As a consequence, more foods use fructose (which is artificially cheap, due to subsidies) versus sucrose (which is artificially expensive, due to high tariffs).
The poster apparently prefers sugar. The fact that the government forces tax money away from him to pay for corn subsidies, and then discriminates against sugar imports specifically, amounts to oppression and dramatically overstepping the proper role of government in the economy.
I second PostgreSQL. It's great code, especially in the lower level parts of the architecture, and the comments are very helpful.
I have mixed feelings about OpenSolaris (admittedly I don't know much about it). I browsed through the ZFS code a little, and it seemed like good code. However, when I looked here: http://cvs.opensolaris.org/source/xref/onnv/onnv-g ate/usr/src/uts/common/fs/zfs/vdev_cache.c I was very confused about the comment beginning "All i/os smaller...", and it got me more confused when I tried to look for the places those variables were used. The comment at the top says the readahead is 128k, but the code looks like it's 64k readahead (look at the VCBS macro).
I asked on #opensolaris before I posted this, and there wasn't any response. I could be wrong and I'd be happy to hear an explanation.
That's a valid point. I don't think it's missed by PG though, it's been discussed before on several occasions. Index-only scans are very similar to two other concepts:
* storing the entire table in a Btree. This makes the primary index useful, at the cost of secondary indexes and other overhead of using a btree.
* Maintaining some cluster order on the heap
Visibility in the index is not out of the question for PG, but there are some complications. I think the main problem is with keeping the visibility information up to date in the indexes when it changes in the tuple. If you have some implementation suggestions I'd be interested to hear them.
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 InnoDB because of the tradeoffs introduced between the engines.
To set the record straight, it wasn't me who said that, it was "itsdapead".
I don't think my posts were anything more than a long-winded way to try to promote my own strict definition of "modular," with more than a hint of postgresql advocacy thrown in:)
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?
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.
No. The memory...
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.
The optimizer is solid most of the time, and there are numerous ways to influence it's choices.
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.
Look, I like Postgresql quite a bit. I think you mistook me for someone who was saying that MySQL is great and Postgresql sucks. You can argue the merits of Postgresql 'till you are blue in the face, but it doesn't make MySQL any less useful.
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.
I don't see how you can say that MySQL storage engines aren't useful, since you've clearly never used them.
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.
Intelligent people use SQLite (or Berkeley DB) for apps that don't require a heavyweight DBMS.
Databases aren't just about performance. Type checking is a big reason why RDBMSs are more prevalent.
Type checking databases are more useful in the same way that a type-checked language is more useful than assembly. Assembly is very simple to program in, but all variables are just bytes. SQLite can't order by date, because dates are strings and don't order the same way. I'm not saying SQLite is bad (not at all, I think it's an interesting project), but simpler does not always mean better.
You should still run a "vacuum full analyze" after schema changes
Do not run VACUUM FULL under normal circumstances. It's a special command that's used to return free space in a table to the operating system by compacting the file and eliminating internal free space. PostgreSQL will reuse this space anyway, so normal operation does not require VACUUM FULL, a plain VACUUM will suffice.
Schema changes may or may not affect the need to run VACUUM FULL, but if you are worried about the performance impact of VACUUM FULL, read the docs, because chances are you don't need it.
MySQL is modular [ from grandparent post ] The point IS pick'n'mix as you put it. [ from parent ]
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.
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.
Just need some in-memory lookups? Memory table engine. Clustered data? NDB.
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.
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.
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 join algorithm than if it were #2. Again, PostgreSQL chooses these plans for you based on cost -- no special configuration required.
If you want modular, it's being able to replace a full text GiST index with a full text GIN index and the application never knows the difference except performance. And by the way, the DDL in postgresql is transactional, so you don't even have to restart the application even if you do some major restructuring of the table (like replacing a table with an updatable view).
there were enough BS nuissances to really put in perspective
Please provide some constructive criticism. Most people who use postgres enjoy it because it has fewer nuisances than any other database (to them). If you provide the details of what is difficult and how your user experience could be improved, that is much more helpful than saying "postgres is hard to use".
by that def, universal coverage isn't "socialism" since govt is a payer, not a provider.
You're splitting hairs. The government will have a huge influence on every aspect of the medical field with universal health care. By your interpretation of the definition of socialism, nothing would be socialism because the government never really provides anything. The most it can do is coerce others to produce goods and services so that the government can distribute those goods and services.
In this case, the doctors are coerced because if they try to open a private practice, they are competing against a subsidized industry, so it's not a level playing field (like private vs public schools). And they already invested all their time and money becoming a doctor, so it's unlikely they'd want to change careers after the fact.
so the military is a the most predominant socialist industry in the U.S.A.
Wrong. More money is spent on Social Security than the entire Department of Defense... and that was in 2004 (I looked up the budget outlays myself) -- a war year.
The military does resemble a socialist institution, but I don't think that's an excuse to encourage more socialism. We have decided in the United States that nobody can be free if anyone can be violent to anyone else for any reason, so we entrusted the proper use of violence to the government (police, military, etc). It's not perfect, but we'd hardly be able to call ourselves a country if factions were warring within.
So, the FDA has never approved a drug that's killed anyone? Boy i'm glad they are there.
Not what I said at all. I was saying that the FDA recognizes that false cures can be deadly. Real cures can be deadly too, of course. But I was responding to the claim that "homeopathic" cures don't kill people (and they do kill people).
all i have to say is, give me one reason why any child, regardless of what economic status they come from, shouldn't be able to get medical care.
We don't have unlimited medical resources, so we can't promise unlimited medical resources to anyone.
The definition of a doctor in the US is a very highly educated individual that society has poured amazing amounts of resources into. It's illegal to provide many types of medical care if you're not one of these people.
So, as a country, the resource of doctors' time (according to our definition of doctor) is quite scarce.
It's not like there are a bunch of doctors just sitting around doing nothing; they're busy. So if we are to allocate more medical resources to a child, we have to deallocate those resources from someone else.
If you have some solution that involves freeing up doctors' time, great, I want to hear it. Or if you have something that reduces the real cost of healthcare (for instance allowing a lower tier of doctors to provide some types of care), I'm listening. Or if you want to increase the output of medical resources somehow, wonderful. But if you just want to provide the care by fiat, you sound crazy, because it's just not going to happen. There are only so many resources, and they're already in use. And a magical government declaration is unlikely to bring any of these costs down or encourage new people to become doctors.
The parent said "HMO," not insurance company. That hits on a very important point: if you buy "insurance" against something that is not financially catastrophic, you are losing big time.
Still, the fact that socialized health care is unconstitutional is not proof that it is somehow inherently bad, which was my point.
True, I just wanted to clarify.
Personally, when considering a policy that's unconstitutional, I would reexamine the policy and see if there might be another policy that does fit within the constraints of the Constitution. For instance, it's worth considering state-level socialized health care in lieu of federal health care. If there is no other good option, I would then consider an amendment.
any of various economic and political theories advocating collective or governmental ownership and administration of the means of production and distribution of goods
I think Universal Health Care fits that definition perfectly, if you replace "goods" with "goods and services".
[The Constitution is] good for trials and judges, not for arguments between people.
The Rule of Law is an argument in and of itself. Not everyone believes in the Rule of Law, and it's legitimate to question whether the Federal government is the right level of government to institute socialized health care.
chose to question the limitations of The Book
Exactly. If you want socialized health care, you should be fighting for an amendment to the Constitution to achieve your goal.
If we don't get an amendment first, all of our other constitutional protections are weakened.
False cures can be very deadly. If you use "alternative treatments" in place of proven scientific medicine, you can end up dead. That's why the FDA standards require that medicines are proven to be effective treatments in addition to being safe. A placebo is safe, but the FDA won't approve it as a cancer drug because such "safe" medicines can still cost lives.
Dealing with the root cause for those who are "on the fence" of supporting terrorism, containing (quietly) the movement, and realizing that somebody, somewhere, will always hate you for an unmitigatable reason are the best ways to deal with it.
The standard answer is that terrorists attack when they are rewarded for doing so, and "dealing with the root causes" carries a serious risk of rewarding terrorism, depending on implementation.
Given the massive expenditure to try and reduce the threat, with no tangible evidence that the threat has decreased, doesn't seem like a good ROI.
I don't think you supported this claim in your argument. I observe that the US has not been attacked since 9/11 and other countries have, such as Spain, the Philippines, and Britain. There have been attempts to attack us that turned out to be unsuccessful, such as the planned attack on our military base.
I'm not really disagreeing with you, but your claims are ahead of your supporting information.
Well, in the grand scheme of things (AIDS, cancer, automobile accidents, floods, tornadoes) I suppose there may be a small percentage of deaths attributed to such actions, and they also serve to scare portions of the population.
You don't acknowledge that the reaction to a threat can affect the severity of the threat.
If we react to terrorism with force, that may result in a different amount of future terrorist activity than if we give the terrorists one of our states as a peace offering.
Similar with the Bird Flu. Maybe it was overhyped or maybe not, but the number of people actually killed so far is almost irrelevant. If our initial reaction to the threat is to ignore it because not enough people are dying, and then it mutates to be transferable between humans, that could result in millions of deaths.
I'm absolutely *not* saying that we should expend unlimited resources fighting every potential threat. We should, however, recognize that threats are sometimes much larger than their current killing rate.
You can get free entry level sysadmin services out of some of these kids for free, and even some less competent kids can be recruited as free first level tech support - turning that down is dumb.
I really want to agree.
However, there are privacy concerns. Sysadmins have access to a lot of important data, some of which is explicitly protected by law from other students.
Without having an effective cost-based planner (like PostgreSQL) the performance for non-trivial (from a planning perspective) queries will never be competitive.
If using a rule-based planner, how does MySQL know when to use a hash aggregate versus a sort + group aggregate? How does it determine join order without keeping statistics about the nature of the data stored in the tables? How does it know whether to hash join vs. merge join? What happens when the nature of the data in the tables changes enough such that what was good before is no longer good?
You can still specify ALLOW_INVALID_DATES as an sqlmode
Let's add some extra values to the integer domain, then make it configurable! We can add values like "eleventeen" or "thirty-twelve"*. When we do some kind of math on those new values, we'll make up some completely arbitrary rule to arrive at a result.
A database should not be configureware. MySQL has a ton of options which actually affect the semantics of user queries. Some options are in the configuration file and some are at table creation time (i.e. MyISAM vs. InnoDB).
That is bad design, completely in conflict with the goal of relational databases. With relational databases, you should be able to change physical storage for performance without affecting user queries.
The option you describe raises all kinds of questions: What if you set it to true, and then unset it? There is no way to tell whether a table contains real dates or some bizarre superset of the date domain. What if it's set to true, then you add invalid dates, then you turn it off, then try to query the data or put it in another table? The whole thing makes so little sense it's mind-boggling.
Innovation has never been strength of Blizzard; historically, Blizzard games have never had revolutionary features.
I disagree that they're not innovative. Blizzard focuses on the subtleties that make games great. Blizzard highly refines the complex interactions between different combinations of units. That is a revolution in games. No other company really cares enough to do that, and it shows.
Slashdot Mirror
While I can appreciate the notion of "knowledge for knowledge's sake", which is infact how most universities started, that is not reality today. Not all disciplines are equal in economic terms.
Universities are for academic education. Nowadays, universities -- especially in fields like Computer Science -- spend so much time focusing on the immediate economic value of the material that we can't honestly call it an academic institution any more. When professors start talking about "industry" and other similar terms, you know you're in vocational school.
There's nothing wrong with vocational school, they are very useful. However, let's call it what it is. If you are spending more time learning a tool than the abstract concepts behind it, chances are you are in vocational school. The only reason we still call it an academic endeavor is because "vocational school" doesn't sound nearly as impressive.
I think this distinction is important because we need both academic institutions and vocational institutions. But if our academic institutions are being infiltrated by vocational training, then we won't have any academic institutions left.
Guess what - even if you are neither, one of most advanced countries in the world using really open standards IS news, even for you.
I think the excitement of a religious victory drives this story more than the mundane details about what open standards will really mean in this instance.
The simple test to determine whether something is based on ideology or reason is whether different facts could change your opinion.
Hypothetically, if the open standards were a mess, and the implementations were much worse than the current closed systems, and productivity went down as a result of using these open standards, reason might say that now is not the time, and that we should refine the standards before recruiting new users.
If that reasoning did not sway someone, then productivity is not the goal, the goal is the ideology of open standards.
I don't think that's a bad ideology, in fact I share the ideology of open standards. But I recognize that there is some ideology there.
I'm sorry but this is a stupid argument that's been pulled out over and over by people who don't want to take responsabilities.
Read the post you replied to again. His point was perfectly valid: due to special interests, there are high tariffs on sugar, and so it is much more expensive in the US than Brazil, for instance. As a consequence, more foods use fructose (which is artificially cheap, due to subsidies) versus sucrose (which is artificially expensive, due to high tariffs).
The poster apparently prefers sugar. The fact that the government forces tax money away from him to pay for corn subsidies, and then discriminates against sugar imports specifically, amounts to oppression and dramatically overstepping the proper role of government in the economy.
I second PostgreSQL. It's great code, especially in the lower level parts of the architecture, and the comments are very helpful.
g ate/usr/src/uts/common/fs/zfs/vdev_cache.c I was very confused about the comment beginning "All i/os smaller...", and it got me more confused when I tried to look for the places those variables were used. The comment at the top says the readahead is 128k, but the code looks like it's 64k readahead (look at the VCBS macro).
I have mixed feelings about OpenSolaris (admittedly I don't know much about it). I browsed through the ZFS code a little, and it seemed like good code. However, when I looked here: http://cvs.opensolaris.org/source/xref/onnv/onnv-
I asked on #opensolaris before I posted this, and there wasn't any response. I could be wrong and I'd be happy to hear an explanation.
That makes index-only reads
That's a valid point. I don't think it's missed by PG though, it's been discussed before on several occasions. Index-only scans are very similar to two other concepts:
* storing the entire table in a Btree. This makes the primary index useful, at the cost of secondary indexes and other overhead of using a btree.
* Maintaining some cluster order on the heap
Visibility in the index is not out of the question for PG, but there are some complications. I think the main problem is with keeping the visibility information up to date in the indexes when it changes in the tuple. If you have some implementation suggestions I'd be interested to hear them.
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 InnoDB because of the tradeoffs introduced between the engines.
:)
To set the record straight, it wasn't me who said that, it was "itsdapead".
I don't think my posts were anything more than a long-winded way to try to promote my own strict definition of "modular," with more than a hint of postgresql advocacy thrown in
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?
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.
No. The memory...
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.
The optimizer is solid most of the time, and there are numerous ways to influence it's choices.
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.
Look, I like Postgresql quite a bit. I think you mistook me for someone who was saying that MySQL is great and Postgresql sucks. You can argue the merits of Postgresql 'till you are blue in the face, but it doesn't make MySQL any less useful.
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.
I don't see how you can say that MySQL storage engines aren't useful, since you've clearly never used them.
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.
Intelligent people use SQLite (or Berkeley DB) for apps that don't require a heavyweight DBMS.
Databases aren't just about performance. Type checking is a big reason why RDBMSs are more prevalent.
Type checking databases are more useful in the same way that a type-checked language is more useful than assembly. Assembly is very simple to program in, but all variables are just bytes. SQLite can't order by date, because dates are strings and don't order the same way. I'm not saying SQLite is bad (not at all, I think it's an interesting project), but simpler does not always mean better.
You should still run a "vacuum full analyze" after schema changes
Do not run VACUUM FULL under normal circumstances. It's a special command that's used to return free space in a table to the operating system by compacting the file and eliminating internal free space. PostgreSQL will reuse this space anyway, so normal operation does not require VACUUM FULL, a plain VACUUM will suffice.
Schema changes may or may not affect the need to run VACUUM FULL, but if you are worried about the performance impact of VACUUM FULL, read the docs, because chances are you don't need it.
MySQL is modular [ from grandparent post ]
t 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.
The point IS pick'n'mix as you put it. [ from parent ]
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.
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.
Just need some in-memory lookups? Memory table engine. Clustered data? NDB.
Seems like the memory engine and NDB are the same thing: http://dev.mysql.com/doc/refman/5.0/en/mysql-clus
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.
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 join algorithm than if it were #2. Again, PostgreSQL chooses these plans for you based on cost -- no special configuration required.
If you want modular, it's being able to replace a full text GiST index with a full text GIN index and the application never knows the difference except performance. And by the way, the DDL in postgresql is transactional, so you don't even have to restart the application even if you do some major restructuring of the table (like replacing a table with an updatable view).
there were enough BS nuissances to really put in perspective
Please provide some constructive criticism. Most people who use postgres enjoy it because it has fewer nuisances than any other database (to them). If you provide the details of what is difficult and how your user experience could be improved, that is much more helpful than saying "postgres is hard to use".
by that def, universal coverage isn't "socialism" since govt is a payer, not a provider.
You're splitting hairs. The government will have a huge influence on every aspect of the medical field with universal health care. By your interpretation of the definition of socialism, nothing would be socialism because the government never really provides anything. The most it can do is coerce others to produce goods and services so that the government can distribute those goods and services.
In this case, the doctors are coerced because if they try to open a private practice, they are competing against a subsidized industry, so it's not a level playing field (like private vs public schools). And they already invested all their time and money becoming a doctor, so it's unlikely they'd want to change careers after the fact.
so the military is a the most predominant socialist industry in the U.S.A.
Wrong. More money is spent on Social Security than the entire Department of Defense... and that was in 2004 (I looked up the budget outlays myself) -- a war year.
The military does resemble a socialist institution, but I don't think that's an excuse to encourage more socialism. We have decided in the United States that nobody can be free if anyone can be violent to anyone else for any reason, so we entrusted the proper use of violence to the government (police, military, etc). It's not perfect, but we'd hardly be able to call ourselves a country if factions were warring within.
So, the FDA has never approved a drug that's killed anyone? Boy i'm glad they are there.
Not what I said at all. I was saying that the FDA recognizes that false cures can be deadly. Real cures can be deadly too, of course. But I was responding to the claim that "homeopathic" cures don't kill people (and they do kill people).
all i have to say is, give me one reason why any child, regardless of what economic status they come from, shouldn't be able to get medical care.
We don't have unlimited medical resources, so we can't promise unlimited medical resources to anyone.
The definition of a doctor in the US is a very highly educated individual that society has poured amazing amounts of resources into. It's illegal to provide many types of medical care if you're not one of these people.
So, as a country, the resource of doctors' time (according to our definition of doctor) is quite scarce.
It's not like there are a bunch of doctors just sitting around doing nothing; they're busy. So if we are to allocate more medical resources to a child, we have to deallocate those resources from someone else.
If you have some solution that involves freeing up doctors' time, great, I want to hear it. Or if you have something that reduces the real cost of healthcare (for instance allowing a lower tier of doctors to provide some types of care), I'm listening. Or if you want to increase the output of medical resources somehow, wonderful. But if you just want to provide the care by fiat, you sound crazy, because it's just not going to happen. There are only so many resources, and they're already in use. And a magical government declaration is unlikely to bring any of these costs down or encourage new people to become doctors.
Thats the whole point of insurance.
The parent said "HMO," not insurance company. That hits on a very important point: if you buy "insurance" against something that is not financially catastrophic, you are losing big time.
Still, the fact that socialized health care is unconstitutional is not proof that it is somehow inherently bad, which was my point.
True, I just wanted to clarify.
Personally, when considering a policy that's unconstitutional, I would reexamine the policy and see if there might be another policy that does fit within the constraints of the Constitution. For instance, it's worth considering state-level socialized health care in lieu of federal health care. If there is no other good option, I would then consider an amendment.
Definition of "Socialism" from m-w.com:
I think Universal Health Care fits that definition perfectly, if you replace "goods" with "goods and services".
[The Constitution is] good for trials and judges, not for arguments between people.
The Rule of Law is an argument in and of itself. Not everyone believes in the Rule of Law, and it's legitimate to question whether the Federal government is the right level of government to institute socialized health care.
chose to question the limitations of The Book
Exactly. If you want socialized health care, you should be fighting for an amendment to the Constitution to achieve your goal.
If we don't get an amendment first, all of our other constitutional protections are weakened.
Because they aren't killing people?
False cures can be very deadly. If you use "alternative treatments" in place of proven scientific medicine, you can end up dead. That's why the FDA standards require that medicines are proven to be effective treatments in addition to being safe. A placebo is safe, but the FDA won't approve it as a cancer drug because such "safe" medicines can still cost lives.
Haven't you seen that episode of South Park?
Dealing with the root cause for those who are "on the fence" of supporting terrorism, containing (quietly) the movement, and realizing that somebody, somewhere, will always hate you for an unmitigatable reason are the best ways to deal with it.
The standard answer is that terrorists attack when they are rewarded for doing so, and "dealing with the root causes" carries a serious risk of rewarding terrorism, depending on implementation.
Given the massive expenditure to try and reduce the threat, with no tangible evidence that the threat has decreased, doesn't seem like a good ROI.
I don't think you supported this claim in your argument. I observe that the US has not been attacked since 9/11 and other countries have, such as Spain, the Philippines, and Britain. There have been attempts to attack us that turned out to be unsuccessful, such as the planned attack on our military base.
I'm not really disagreeing with you, but your claims are ahead of your supporting information.
Well, in the grand scheme of things (AIDS, cancer, automobile accidents, floods, tornadoes) I suppose there may be a small percentage of deaths attributed to such actions, and they also serve to scare portions of the population.
You don't acknowledge that the reaction to a threat can affect the severity of the threat.
If we react to terrorism with force, that may result in a different amount of future terrorist activity than if we give the terrorists one of our states as a peace offering.
Similar with the Bird Flu. Maybe it was overhyped or maybe not, but the number of people actually killed so far is almost irrelevant. If our initial reaction to the threat is to ignore it because not enough people are dying, and then it mutates to be transferable between humans, that could result in millions of deaths.
I'm absolutely *not* saying that we should expend unlimited resources fighting every potential threat. We should, however, recognize that threats are sometimes much larger than their current killing rate.
You can get free entry level sysadmin services out of some of these kids for free, and even some less competent kids can be recruited as free first level tech support - turning that down is dumb.
I really want to agree.
However, there are privacy concerns. Sysadmins have access to a lot of important data, some of which is explicitly protected by law from other students.
The real deal on RDBMs...there are 3 serious products. Oracle, Microsoft and IBM.
You haven't said much to support that argument. PostgreSQL is quite a serious RDBMS, and I see no reason why it isn't out ahead of MS SQL Server.
Another one:
Does MySQL still use a rule-based planner?
Without having an effective cost-based planner (like PostgreSQL) the performance for non-trivial (from a planning perspective) queries will never be competitive.
If using a rule-based planner, how does MySQL know when to use a hash aggregate versus a sort + group aggregate? How does it determine join order without keeping statistics about the nature of the data stored in the tables? How does it know whether to hash join vs. merge join? What happens when the nature of the data in the tables changes enough such that what was good before is no longer good?
A cost based planner is crucial.
You can still specify ALLOW_INVALID_DATES as an sqlmode
Let's add some extra values to the integer domain, then make it configurable! We can add values like "eleventeen" or "thirty-twelve"*. When we do some kind of math on those new values, we'll make up some completely arbitrary rule to arrive at a result.
A database should not be configureware. MySQL has a ton of options which actually affect the semantics of user queries. Some options are in the configuration file and some are at table creation time (i.e. MyISAM vs. InnoDB).
That is bad design, completely in conflict with the goal of relational databases. With relational databases, you should be able to change physical storage for performance without affecting user queries.
The option you describe raises all kinds of questions: What if you set it to true, and then unset it? There is no way to tell whether a table contains real dates or some bizarre superset of the date domain. What if it's set to true, then you add invalid dates, then you turn it off, then try to query the data or put it in another table? The whole thing makes so little sense it's mind-boggling.
*: with credit to the author of Calvin and Hobbes
Innovation has never been strength of Blizzard; historically, Blizzard games have never had revolutionary features.
I disagree that they're not innovative. Blizzard focuses on the subtleties that make games great. Blizzard highly refines the complex interactions between different combinations of units. That is a revolution in games. No other company really cares enough to do that, and it shows.