Skip site navigation (1) Skip section navigation (2)

Re: 2nd Level Buffer Cache

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Jim Nasby <jim(at)nasby(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, rsmogura(at)softperience(dot)eu, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 2nd Level Buffer Cache
Date: 2011-03-18 23:55:29
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 3/18/11 11:15 AM, Jim Nasby wrote:
> To take the opposite approach... has anyone looked at having the OS just manage all caching for us? Something like MMAPed shared buffers? Even if we find the issue with large shared buffers, we still can't dedicate serious amounts of memory to them because of work_mem issues. Granted, that's something else on the TODO list, but it really seems like we're re-inventing the wheels that the OS has already created here...

As far as I know, no OS has a more sophisticated approach to eviction
than LRU.  And clock-sweep is a significant improvement on performance
over LRU for frequently accessed database objects ... plus our
optimizations around not overwriting the whole cache for things like VACUUM.

2-level caches work well for a variety of applications.

Now, what would be *really* useful is some way to avoid all the data
copying we do between shared_buffers and the FS cache.

                                  -- Josh Berkus
                                     PostgreSQL Experts Inc.

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2011-03-19 00:52:37
Subject: Re: Re: [COMMITTERS] pgsql: Basic Recovery Control functions for use in Hot Standby. Pause,
Previous:From: Radosław SmoguraDate: 2011-03-18 23:35:00
Subject: Re: 2nd Level Buffer Cache

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group