| From: | Jim Nasby <jim(at)nasby(dot)net> |
|---|---|
| To: | Gregory Smith <gregsmithpgsql(at)gmail(dot)com>, Mel Gorman <mgorman(at)suse(dot)de>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
| Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, Kevin Grittner <kgrittn(at)ymail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Joshua Drake <jd(at)commandprompt(dot)com>, Claudio Freire <klaussfreire(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "lsf-pc(at)lists(dot)linux-foundation(dot)org" <lsf-pc(at)lists(dot)linux-foundation(dot)org>, Magnus Hagander <magnus(at)hagander(dot)net> |
| Subject: | Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance |
| Date: | 2014-01-23 01:08:58 |
| Message-ID: | 52E06BAA.4000406@nasby.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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 regression suite. Ugly "we never though that would happen" situations seems at the root of many of the kernel performance regressions people here get nailed by.
FWIW, there are some scenarios where we could potentially provide additional info to the kernel scheduler; stuff that we know 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 from a 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 list of 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 only does it understand the underlying hardware, it can also see everything else that's going on.
--
Jim C. Nasby, Data Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim Nasby | 2014-01-23 01:14:40 | Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance |
| Previous Message | Peter Eisentraut | 2014-01-23 01:06:10 | Re: [PATCH] Relocation of tablespaces in pg_basebackup |