Re: Linux kernel impact on PostgreSQL performance - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: Linux kernel impact on PostgreSQL performance
Date
Msg-id 52D45304.9010100@nasby.net
Whole thread Raw
In response to Re: Linux kernel impact on PostgreSQL performance  (Claudio Freire <klaussfreire@gmail.com>)
List pgsql-hackers
On 1/13/14, 2:37 PM, Claudio Freire wrote:
> On Mon, Jan 13, 2014 at 5:32 PM, Jim Nasby <jim@nasby.net> wrote:
>>>
>>> That's my point. In terms of kernel-postgres interaction, it's fairly
>>> simple.
>>>
>>> What's not so simple, is figuring out what policy to use. Remember,
>>> you cannot tell the kernel to put some page in its page cache without
>>> reading it or writing it. So, once you make the kernel forget a page,
>>> evicting it from shared buffers becomes quite expensive.
>>
>>
>> Well, if we were to collaborate with the kernel community on this then
>> presumably we can do better than that for eviction... even to the extent of
>> "here's some data from this range in this file. It's (clean|dirty). Put it
>> in your cache. Just trust me on this."
>
>
> If I had a kernel developer hat, I'd put it on to say: I don't think
> allowing that last bit is wise for a kernel.
>
> It would violate oh-so-many separation rules and open an oh-so-big can-o-worms.

Yeah, if it were me I'd probably want to keep a hash of the page and it's address and only accept putting a page back
intothe kernel if it matched my hash. Otherwise you'd just have to treat it as a write.
 
-- 
Jim C. Nasby, Data Architect                       jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net



pgsql-hackers by date:

Previous
From: Marti Raudsepp
Date:
Subject: Re: PoC: Partial sort
Next
From: Heikki Linnakangas
Date:
Subject: Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE