On 1/17/14, 2:24 PM, Gregory Smith wrote:
> I am skeptical that the database will take over very much of this work and perform better than the Linux kernel does.
My take is that our most useful role would be providing test cases kernel developers can add to a performance
regressionsuite. Ugly "we never though that would happen" situations seems at the root of many of the kernel
performanceregressions people here get nailed by.
FWIW, there are some scenarios where we could potentially provide additional info to the kernel scheduler; stuff that
weknow that it never will.
For example, if we have a limit clause we can (sometimes) provide a rough estimate of how many pages we'll need to read
froma relation.
Probably more useful is the case of index scans; if we pre-read more data from the index we could hand the kernel a
listof base relation blocks that we know we'll need.
There's some other things that have been mentioned, such as cases where files will only be accessed sequentially.
Outside of that though, the kernel is going to be in a way better position to schedule IO than we will ever be. Not
onlydoes it understand the underlying hardware, it can also see everything else that's going on.
--
Jim C. Nasby, Data Architect jim@nasby.net
512.569.9461 (cell) http://jim.nasby.net
