Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance
От | Jim Nasby |
---|---|
Тема | Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance |
Дата | |
Msg-id | 52E06BAA.4000406@nasby.net обсуждение исходный текст |
Ответ на | Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance (Gregory Smith <gregsmithpgsql@gmail.com>) |
Ответы |
Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: