Swapping to disk is slow. That is why I added more memory so my system would cache the swap file.;)
Reading from disk is slow compared to memory. If the lack of swap space prevents you from swapping out a page, you may end up doing more I/O than if you had swapped it out.
There are a lot of details in the full story here, but here's a toy example. Assume writing and reading a single block in disk always costs the same, and that memory pages are the same size as disk blocks. Compare the cost of these two scenarios:
Processes request the same filesystem block three times. To satisfy these requests, you go to disk each time. Total cost incurred: 3 disk I/Os.
Processes request the same filesystem block three times. For first request, you swap a memory page out, read the filesystem block, and cache it; cost is 2 disk I/Os. For the second and third request, you give them the cached block. Then the page you swapped out gets touched, so you swap it back in; cost is 1 disk I/O. Total cost incurrend: 3 disk I/Os.
Swapping in and out breaks even in this case. It's an extremely simplistic example, but it demonstrates the point: swapping pages out and back in costs you some disk I/O, but reading filesystem blocks from disk also costs you some disk I/O. You don't actually want to minimize swapping; you want to minimize disk I/O, whether it's from swapping or reading a filesystem. Swapping in fact helps you minimize disk I/O, and that's why you always want to have some swap.
The point of swap space isn't to kick in when you run out of physical memory. The point of swap space is to allow the kernel to make use the most efficient use of your RAM, by swapping out the contents of infrequently accessed memory pages, and putting that memory to better use, like caching frequently accessed disk blocks.
If you have no swap space at all, any memory pages that your processes are hardly using have to stick around in memory forever, even if you'd get better performance by swapping the contents out and using it for caching disk blocks. So seriously, you should add some swap space, at least as much as your RAM.
Now given that I'm the man in the middle, and that self-signed certificates are easily replaced (for most people) with non-self-signed certificates, it seems like the only argument for encrypted-but-not-authenticated SSL is that it makes non-directed attacks slightly harder.
Yes, I know that encryption without authentication offers way, way weaker security guarantees than authenticated connections. I still do think it's valuable, and that most content transmitted over the wires should be encrypted by default, but for the sake of argument, let's grant your point: an unauthenticated encrypted connection is no more secure than an unencrypted, unauthenticated connection. Given that premise, why should the browser make it any harder for the user to access a site with a self-signed cert than it does for an unencrypted, unauthenticated site?
If you're going to go to all the trouble of setting up SSL certificates, why don't you actually leverage the web of trust and *sign* them, thus mitigating BOTH directed and drag-net attacks on your traffic.
Again, let's grant the point for the sake of argument. Why should the user of a website be penalized for the bad choices of the administrator of the website? Clearly, the browser should try to make it clear that this site is not "secure"; but why should it make the site any harder to access?
My view, which I guess you'd agree with, is that it's best to start with clean, simple code. Usually, that's plenty fast. If performance tests prove that you have a problem, and a profiler shows you the source of the problem, only then should you sacrifice clarity for speed. And you should only do just enough to meet your performance goals.
While this is overall not bad advice, it's still not quite right, IMHO. The problem is that you're equating "simple" with "clean" and "unclear" with "fast." This association is wrong. There are many cases where you have the choice between a simple but slow solution to a problem, and a complex but faster one, and you should pick the complex one when performance is critical. But the key thing here is that you should still write the complex solution clearly. The complex solution should be harder to understand because it's trying to do something more complex, and the code should still be written to help the reader understand what is happening. Very often, it suffices to put a medium-sized comment before the tricky code, with an informal description of the algorithm.
And yet the clueless-nerd-squad was up in arms when Firefox made it *really hard* to accidentally hit "OK" and wind up trusting a totally bogus SSL certificate.
I don't know what the clueless nerd squad did, but very many people pointed out the real problem: the brower's UI equated "encrypted connection" with "authenticated site." The correct behavior is to treat encrypted sites with self-signed certs the same way as unencrypted sites.
I guess all those people crashing their cars don't bear any responsibility either. It must be poor design on the part of the auto makers, right?
Actually, the problem here is that no matter what the correct balance of responsibility should be between the automakers and the drivers, if you don't pursue the poor design hypothesis, you won't actually fix real problems with car design. The car makers will spend less money on design and manufacturing, but the public will pay far more than the car makers save in increased injury and mortality rates.
Functors and generators will do the same thing for you in a more mainstream languages like C++ and Python. And they'll be a hell of a lot more understandable to your average still-wet-behind-the-ears programmer.
Um, are Python generators any easier to understand than lazy evaluation to your "your average still-wet-behind-the-ears programmer"? The only way I can imagine this being so is that your programmer already did the hard work to learn C++ or Python, but didn't do any such work for Haskell--which begs the question, frankly.
Python generators ain't easy stuff. They're completely out of left field with regards to the rest of the language's stack-based flow control. How is the concept of reentering a local execution context that you exited before any simpler than lazy evaluation?
How is 80% ownership of a failed company good for US Taxpayers...?
I don't think that GP meant to imply this is "good" for taxpayers; rather, that it was simply not as outrageously bad as had been suggested. GP was responding to GGP's assertion that AIG had gotten $85 billion with no strings attached. The point is that government's 80% senior preferred stake is a big string attached to the money. It means that the government must be paid before AIG's common and preferred shareholders, and that in a bankruptcy or liquidation, the common and preferred shareholders must be completely wiped out before the government can take a loss in its share.
In effect, there are three interested parties in this deal, and each one's stake must be wiped out before the next one takes a loss:
AIG's shareholders
The government, and thus indirectly, the taxpayers
AIG's creditors
The deal is structured this way in order to rescue AIG's creditors without rescuing its shareholders (which you can still call "bad" if you like). This is "good" only in the sense that taxpayers' money doesn't go to help AIG's shareholders, who are still being made to bear the risk of being wiped out by their company's bad deals.
Let's hope it turns out to be worth something. AIG's stock price 52 week high was $70.13, and it's now trading for $2.69.
You can't straightforwardly judge the value of the government's stake in AIG using the current price of the common stock. Yes, AIG's common stock's price is currently that, but that's after the government took an 80% stake in the company--a move which, all other things being equal (which they are not), makes each public share worth 20% of what it was worth before.
In addition, the government has senior preferred shares, which means that all of the common and preferred shareholders must be wiped out before the government takes a hit. This makes the government's shares more valuable than the common.
It's still all but impossible to write real, large, complex, maintainable systems in Scheme without using implementation-dependent extensions for module systems, user-defined types and macros. Therefore, those references that you mention will not be enough, and always will need to be supplemented by implementation documentation. (R6RS Scheme aims to correct this, but it's still too recent to have been widely adopted.)
What's worse, however, is that while many Scheme implementations come with good reference manuals, there is much less in the way of tutorial material that demonstrates how to use it to build complex software. Most people learn such things from example, so language and library references, while essential, don't really help most people get started.
(I do work at a job where I get paid to write Scheme software, so no, I don't say this because I'm a hater...)
Can we at least agree that the dictionary should only contain words and their usages that would be acceptable in a published work of nonfiction?
So we should force dictionaries to omit terms that appear only in published fiction? Um, what for? That sounds (a) stupid, (b) like it would prevent dictionaries from specializing for different uses by using different selection criteria, and (c) stupid. (Should we knock out all the entries in the OED that only appear in works of fiction?)
Many dictionaries will already label informal entries or usages as such. Read the damn dictionaries' methodology, pick the one that serves you best, learn its entry format, and use it correctly.
If you're one of the people who has enough static IP addresses to serve your needs, you're better off with IPv4, because that will make sure you're among the few who do.
Why would you care whether other people didn't have enough IP to serve their needs? Or, in other words, as long as you don't get fewer IP addresses than you have now, why would you oppose moving to IPv6?
Response 3 is right on the cusp of racism. It's not necessarily different from 2, it's just the point where you go from specifics about behavior to generalizations about the person. Those generalizations can be drawn from two sources: the behavior of the individual, and stereotypes about the race. If you are drawing your generalization from 2 it is not racist; if you are drawing your generalization from 3 it is.
You're assuming that the response to the hypothetical green-skinned dude is based on subjective reactions to objective observations; i.e., for example, you observe that he interrupts you a lot, and then which conclusion one draws is influenced by biases.
The problem is that deep-seated biases will go deeper than just influencing which conclusion you draw from what you observe; they will influence what you observe. You may only be bothered so much about the guy interrupting you because his skin is green. Behaviors that you would hardly notice or remark on from somebody of a positively valued skin color will be seen as glaring coming from a green-skinned dude.
The term 'racist" carries with it strong connotations of ignorance and bigotry, and it is unfair to call someone who it honestly attempting to be fair and equal with all people regardless of race racist if they still possess some small racial bias outside a strictly academic field.
Racism is too important a problem for so-called "white" people to approach it narcissistically by reducing it to the purity or impurity of their own personal, private intentions. This whole "don't call me a racist" line that you're pushing here is disingenious; it recasts the issue of racism so that instead of focusing on the objective problems and obstacles faced by people of color, it becomes about white people's attitudes and intentions. So instead of having discussions about the unequal allocation of funds to schools, or investment into inner city neighborhoods, the discussions become about stupid things like how supposedly Trent Lott does not bear any ill will toward black people. Give me a break.
The real issue here is that our OS's mechanisms for controlling resource sharing and protection among cooperating concurrent "lines" of execution (to avoid the words "process" or "thread") aren't as fine-grained as they could be. It's nearly an all-or-nothing choice between everything-shared ("threads") or very-little-shared ("processes"). Processes do get the advantage that the OS allows them to selectively share memory with each other, but threads don't get the natural counterpart, the ability to define their own thread-local memory domains, protected from other threads. A more powerful OS concurrency API would allow you to say exactly what things are shared and which are private to each unit of concurrent execution.
A thread per tab model does protect you from a rogue Javascript freezing the browser's UI, but it doesn't protect you from a poorly written plugin that does something stupid like dereference a NULL pointer.
Chrome's doing JIT compilation of Javascript. In this context, separating the broswer into multiple processes protects you from bugs in the JIT compiler that produce native code that makes memory access errors.
Separating the browser into one process per tab only helps for the fragmentation problem in the case of memory that is truly private to each process. It doesn't help at all in the case of memory that's shared between processes. If that shared memory is managed as a heap like malloc and free do, it can still fragment. (And it's important to point out that the shared memory doesn't need to be managed like that; a custom memory management scheme tailored precisely to the way it's used could have zero fragmentation.)
There is no way of knowing the memory and performance costs of the multi-process browser without having a lot more detail about precisely which things are private to each process, and which are shared. The comic does nothing to tell us to what Chrome is sharing and what's private to each process, nor how any shared memory is managed.
The multi-process architecture will carry additional memory overhead, but done correctly, it will scale up much better than linearly. The real costs are the costs of process creation and switching in the OS, plus the costs of the inter-process communication method. Using shared memory for the latter is cheap, but it can potentially make one process bring down the others, defeating the purpose of isolating each page into a process; it's a balancing act, and the memory overhead really depends on what tradeoffs one picks here.
Actually, I take that back. The only real overhead is the OS overhead for separate processes.
The architectural choice of what memory contents should be shared between processes and which should be private aren't specific to the multi-process architecture. The same choices and tradeoffs exist in a multi-threaded application; you can choose between having each thread have its own copy of some piece of memory (uses more memory, but isolates each thread from the others), or have all the threads share it (uses less memory, but access must be synchronized, and any bugs involving that shared memory may make one thread bring others down).
Because it's bloated as a single app, but less bloated then opening up a new process (or more than one!) for every single web page loaded. Until every computer in use has multi-gigabyte memory, including handheld devices, there will be a need for something lighter than webkit
First of all, WebKit itself doesn't impose the multi-process model that Google's Chrome uses. For example, Safari uses WebKit, and it runs as a single process.
With that cleared up, now, here's the more important flawed assumption in your post: that having the broswer use n processes to display n pages will require n times as much memory as doing it all with n threads in one process. That's far from true, because such a browser can be architected so that the processes use shared memory for all shared resources and state.
The multi-process architecture will carry additional memory overhead, but done correctly, it will scale up much better than linearly. The real costs are the costs of process creation and switching in the OS, plus the costs of the inter-process communication method. Using shared memory for the latter is cheap, but it can potentially make one process bring down the others, defeating the purpose of isolating each page into a process; it's a balancing act, and the memory overhead really depends on what tradeoffs one picks here.
The EPA changed its fuel economy standards in 2008, and perhaps other times between 1989 and then. The 2007 Prius is rated at 60 mpg city, 51 highway; the 2008, which is really the same car, is rated at 48/45. So you definitely can't compare the 1989 numbers with the 2008.
The optimizer in an Oracle database (and others, I'm sure) actually determines "access path" based on resource cost. It automatically generates many different access paths, and based on known statistics about the underlying objects in question, determines the cost in resources to execute that path (CPU, memory, disk I/O, etc, etc), then chooses the one with the least cost.
Leaving aside the issue of where the "query rewriter" ends and where the "optimizer" starts, no, that's not all that happens to go from SQL query against a database to execution plan. Access paths are things like choosing various types of index access or table scans. However, many optimizations to SQL statements are purely syntactic, and are based on semantic equivalences guaranteed by the relational algebra.
An esay example: a restriction that applies to just one of the relations in a join can be pushed inside the join onto that relation. For example, if you have restrict(join(A,B), predicate_over_A), you can transform that relational algebra expression into join(restrict(A, predicate_over_A), B). This optimization is called "pushing the restriction," and it reduces the number of rows that have to be processed for the join.
So, database query optimization, deep down, involves reasoning both about equivalent query transformations and hardware resource costs for various operations.
IIRC, Oracle has features for parallelizing query execution automatically for queries. These features are enabled by various combinations of session settings and query hints, and can parallelize execution either within a single server machine, or across multiple machines in a cluster.
I'm going to speculate wildly and say that you could probably write a SQL interpreter using a functional style as well, and that good ones probably already do.
It's deeper than that. Save for relvar update operations, relational algebra just is a functional language. Relational algebra really just consists of relation types and higher-order functional operators over them. For example, relational restriction is an operator that takes a relation over a tuple type and a predicate over that tuple type, and returns another relation over the same tuple type.
Sushi and sashimi are meant to highlight the natural taste and texture of extremely fresh ingredients. For many kinds of sushi toppings, this means that they're served completely raw and unadorned, but not for all. Many sushi toppings are very lightly cooked (e.g., by brief boiling or steaming); some items also are served with a sauce that improves their flavor; others may be raw but marinated.
The association of "sushi" with "raw fish" outside of Japan is because non-Japanese find the idea of eating raw fish a bit shocking, but really, the best explanation of sushi is extremely fresh seafood, with the bare minimum of preparation needed to make it enjoyable, eaten with vinegared rice.
Read the summary of the study's conclusion again. What the study claims to demonstrate isn't that polygamists live longer than other men in their own society; what it demonstrates is that in societies where a minority of the men have multiple wives, the mean longevity of all men is longer.
Note the following two things that follow from this:
It hasn't been demonstrated that the extra mean longevity in the population as a whole is due to the extra longevity of the polygamists. Nobody's gonna be surprised if more research shows that is the case, but let's not get ahead of ourselves
Far more importantly, if it is indeed the case that the small number of polygamists truly does push up the average life expectancy of the whole community, this means that the men who don't have multiple wives aren't pulling it down.
The second point I just made is at odds with what you're telling us here:
On the flipside, look at the polygamist societies - in Middle Eastern/African muslim societies, those who aren't going to reach 60 (read: the poor) usually kill themselves off FAR faster in various tribal conflicts and wars.
For this to be consistent with the results of the study, the negative effect of such early deaths on average longevity must be smaller than the positive effect that the polygamists have on the same statistic. Which suggests you're totally overblowing this by reasoning on the basis of stereotypes.
Slashdot Mirror
Reading from disk is slow compared to memory. If the lack of swap space prevents you from swapping out a page, you may end up doing more I/O than if you had swapped it out.
There are a lot of details in the full story here, but here's a toy example. Assume writing and reading a single block in disk always costs the same, and that memory pages are the same size as disk blocks. Compare the cost of these two scenarios:
Swapping in and out breaks even in this case. It's an extremely simplistic example, but it demonstrates the point: swapping pages out and back in costs you some disk I/O, but reading filesystem blocks from disk also costs you some disk I/O. You don't actually want to minimize swapping; you want to minimize disk I/O, whether it's from swapping or reading a filesystem. Swapping in fact helps you minimize disk I/O, and that's why you always want to have some swap.
The point of swap space isn't to kick in when you run out of physical memory. The point of swap space is to allow the kernel to make use the most efficient use of your RAM, by swapping out the contents of infrequently accessed memory pages, and putting that memory to better use, like caching frequently accessed disk blocks.
If you have no swap space at all, any memory pages that your processes are hardly using have to stick around in memory forever, even if you'd get better performance by swapping the contents out and using it for caching disk blocks. So seriously, you should add some swap space, at least as much as your RAM.
Yes, I know that encryption without authentication offers way, way weaker security guarantees than authenticated connections. I still do think it's valuable, and that most content transmitted over the wires should be encrypted by default, but for the sake of argument, let's grant your point: an unauthenticated encrypted connection is no more secure than an unencrypted, unauthenticated connection. Given that premise, why should the browser make it any harder for the user to access a site with a self-signed cert than it does for an unencrypted, unauthenticated site?
Again, let's grant the point for the sake of argument. Why should the user of a website be penalized for the bad choices of the administrator of the website? Clearly, the browser should try to make it clear that this site is not "secure"; but why should it make the site any harder to access?
While this is overall not bad advice, it's still not quite right, IMHO. The problem is that you're equating "simple" with "clean" and "unclear" with "fast." This association is wrong. There are many cases where you have the choice between a simple but slow solution to a problem, and a complex but faster one, and you should pick the complex one when performance is critical. But the key thing here is that you should still write the complex solution clearly. The complex solution should be harder to understand because it's trying to do something more complex, and the code should still be written to help the reader understand what is happening. Very often, it suffices to put a medium-sized comment before the tricky code, with an informal description of the algorithm.
I don't know what the clueless nerd squad did, but very many people pointed out the real problem: the brower's UI equated "encrypted connection" with "authenticated site." The correct behavior is to treat encrypted sites with self-signed certs the same way as unencrypted sites.
Actually, the problem here is that no matter what the correct balance of responsibility should be between the automakers and the drivers, if you don't pursue the poor design hypothesis, you won't actually fix real problems with car design. The car makers will spend less money on design and manufacturing, but the public will pay far more than the car makers save in increased injury and mortality rates.
Um, are Python generators any easier to understand than lazy evaluation to your "your average still-wet-behind-the-ears programmer"? The only way I can imagine this being so is that your programmer already did the hard work to learn C++ or Python, but didn't do any such work for Haskell--which begs the question, frankly.
Python generators ain't easy stuff. They're completely out of left field with regards to the rest of the language's stack-based flow control. How is the concept of reentering a local execution context that you exited before any simpler than lazy evaluation?
I don't think that GP meant to imply this is "good" for taxpayers; rather, that it was simply not as outrageously bad as had been suggested. GP was responding to GGP's assertion that AIG had gotten $85 billion with no strings attached. The point is that government's 80% senior preferred stake is a big string attached to the money. It means that the government must be paid before AIG's common and preferred shareholders, and that in a bankruptcy or liquidation, the common and preferred shareholders must be completely wiped out before the government can take a loss in its share.
In effect, there are three interested parties in this deal, and each one's stake must be wiped out before the next one takes a loss:
The deal is structured this way in order to rescue AIG's creditors without rescuing its shareholders (which you can still call "bad" if you like). This is "good" only in the sense that taxpayers' money doesn't go to help AIG's shareholders, who are still being made to bear the risk of being wiped out by their company's bad deals.
You can't straightforwardly judge the value of the government's stake in AIG using the current price of the common stock. Yes, AIG's common stock's price is currently that, but that's after the government took an 80% stake in the company--a move which, all other things being equal (which they are not), makes each public share worth 20% of what it was worth before.
In addition, the government has senior preferred shares, which means that all of the common and preferred shareholders must be wiped out before the government takes a hit. This makes the government's shares more valuable than the common.
It's still all but impossible to write real, large, complex, maintainable systems in Scheme without using implementation-dependent extensions for module systems, user-defined types and macros. Therefore, those references that you mention will not be enough, and always will need to be supplemented by implementation documentation. (R6RS Scheme aims to correct this, but it's still too recent to have been widely adopted.)
What's worse, however, is that while many Scheme implementations come with good reference manuals, there is much less in the way of tutorial material that demonstrates how to use it to build complex software. Most people learn such things from example, so language and library references, while essential, don't really help most people get started.
(I do work at a job where I get paid to write Scheme software, so no, I don't say this because I'm a hater...)
So we should force dictionaries to omit terms that appear only in published fiction? Um, what for? That sounds (a) stupid, (b) like it would prevent dictionaries from specializing for different uses by using different selection criteria, and (c) stupid. (Should we knock out all the entries in the OED that only appear in works of fiction?)
Many dictionaries will already label informal entries or usages as such. Read the damn dictionaries' methodology, pick the one that serves you best, learn its entry format, and use it correctly.
Why would you care whether other people didn't have enough IP to serve their needs? Or, in other words, as long as you don't get fewer IP addresses than you have now, why would you oppose moving to IPv6?
You're assuming that the response to the hypothetical green-skinned dude is based on subjective reactions to objective observations; i.e., for example, you observe that he interrupts you a lot, and then which conclusion one draws is influenced by biases.
The problem is that deep-seated biases will go deeper than just influencing which conclusion you draw from what you observe; they will influence what you observe. You may only be bothered so much about the guy interrupting you because his skin is green. Behaviors that you would hardly notice or remark on from somebody of a positively valued skin color will be seen as glaring coming from a green-skinned dude.
Racism is too important a problem for so-called "white" people to approach it narcissistically by reducing it to the purity or impurity of their own personal, private intentions. This whole "don't call me a racist" line that you're pushing here is disingenious; it recasts the issue of racism so that instead of focusing on the objective problems and obstacles faced by people of color, it becomes about white people's attitudes and intentions. So instead of having discussions about the unequal allocation of funds to schools, or investment into inner city neighborhoods, the discussions become about stupid things like how supposedly Trent Lott does not bear any ill will toward black people. Give me a break.
The real issue here is that our OS's mechanisms for controlling resource sharing and protection among cooperating concurrent "lines" of execution (to avoid the words "process" or "thread") aren't as fine-grained as they could be. It's nearly an all-or-nothing choice between everything-shared ("threads") or very-little-shared ("processes"). Processes do get the advantage that the OS allows them to selectively share memory with each other, but threads don't get the natural counterpart, the ability to define their own thread-local memory domains, protected from other threads. A more powerful OS concurrency API would allow you to say exactly what things are shared and which are private to each unit of concurrent execution.
Chrome's doing JIT compilation of Javascript. In this context, separating the broswer into multiple processes protects you from bugs in the JIT compiler that produce native code that makes memory access errors.
Separating the browser into one process per tab only helps for the fragmentation problem in the case of memory that is truly private to each process. It doesn't help at all in the case of memory that's shared between processes. If that shared memory is managed as a heap like malloc and free do, it can still fragment. (And it's important to point out that the shared memory doesn't need to be managed like that; a custom memory management scheme tailored precisely to the way it's used could have zero fragmentation.)
There is no way of knowing the memory and performance costs of the multi-process browser without having a lot more detail about precisely which things are private to each process, and which are shared. The comic does nothing to tell us to what Chrome is sharing and what's private to each process, nor how any shared memory is managed.
Actually, I take that back. The only real overhead is the OS overhead for separate processes.
The architectural choice of what memory contents should be shared between processes and which should be private aren't specific to the multi-process architecture. The same choices and tradeoffs exist in a multi-threaded application; you can choose between having each thread have its own copy of some piece of memory (uses more memory, but isolates each thread from the others), or have all the threads share it (uses less memory, but access must be synchronized, and any bugs involving that shared memory may make one thread bring others down).
First of all, WebKit itself doesn't impose the multi-process model that Google's Chrome uses. For example, Safari uses WebKit, and it runs as a single process.
With that cleared up, now, here's the more important flawed assumption in your post: that having the broswer use n processes to display n pages will require n times as much memory as doing it all with n threads in one process. That's far from true, because such a browser can be architected so that the processes use shared memory for all shared resources and state.
The multi-process architecture will carry additional memory overhead, but done correctly, it will scale up much better than linearly. The real costs are the costs of process creation and switching in the OS, plus the costs of the inter-process communication method. Using shared memory for the latter is cheap, but it can potentially make one process bring down the others, defeating the purpose of isolating each page into a process; it's a balancing act, and the memory overhead really depends on what tradeoffs one picks here.
The EPA changed its fuel economy standards in 2008, and perhaps other times between 1989 and then. The 2007 Prius is rated at 60 mpg city, 51 highway; the 2008, which is really the same car, is rated at 48/45. So you definitely can't compare the 1989 numbers with the 2008.
Leaving aside the issue of where the "query rewriter" ends and where the "optimizer" starts, no, that's not all that happens to go from SQL query against a database to execution plan. Access paths are things like choosing various types of index access or table scans. However, many optimizations to SQL statements are purely syntactic, and are based on semantic equivalences guaranteed by the relational algebra.
An esay example: a restriction that applies to just one of the relations in a join can be pushed inside the join onto that relation. For example, if you have restrict(join(A,B), predicate_over_A), you can transform that relational algebra expression into join(restrict(A, predicate_over_A), B). This optimization is called "pushing the restriction," and it reduces the number of rows that have to be processed for the join.
So, database query optimization, deep down, involves reasoning both about equivalent query transformations and hardware resource costs for various operations.
IIRC, Oracle has features for parallelizing query execution automatically for queries. These features are enabled by various combinations of session settings and query hints, and can parallelize execution either within a single server machine, or across multiple machines in a cluster.
It's deeper than that. Save for relvar update operations, relational algebra just is a functional language. Relational algebra really just consists of relation types and higher-order functional operators over them. For example, relational restriction is an operator that takes a relation over a tuple type and a predicate over that tuple type, and returns another relation over the same tuple type.
Doesn't Oracle have this sort of feature already, without the Google "MapReduce" buzzword buzz?
Sushi and sashimi are meant to highlight the natural taste and texture of extremely fresh ingredients. For many kinds of sushi toppings, this means that they're served completely raw and unadorned, but not for all. Many sushi toppings are very lightly cooked (e.g., by brief boiling or steaming); some items also are served with a sauce that improves their flavor; others may be raw but marinated.
The association of "sushi" with "raw fish" outside of Japan is because non-Japanese find the idea of eating raw fish a bit shocking, but really, the best explanation of sushi is extremely fresh seafood, with the bare minimum of preparation needed to make it enjoyable, eaten with vinegared rice.
Read the summary of the study's conclusion again. What the study claims to demonstrate isn't that polygamists live longer than other men in their own society; what it demonstrates is that in societies where a minority of the men have multiple wives, the mean longevity of all men is longer.
Note the following two things that follow from this:
The second point I just made is at odds with what you're telling us here:
For this to be consistent with the results of the study, the negative effect of such early deaths on average longevity must be smaller than the positive effect that the polygamists have on the same statistic. Which suggests you're totally overblowing this by reasoning on the basis of stereotypes.