Re: Clock sweep not caching enough B-Tree leaf pages?
Peter Geoghegan <pg@heroku.com>
From: Peter Geoghegan <pg@heroku.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: Robert Haas <robertmhaas@gmail.com>, Greg Stark <stark@mit.edu>,
Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2014-04-17T17:54:43Z
Lists: pgsql-hackers
On Thu, Apr 17, 2014 at 9:21 AM, Stephen Frost <sfrost@snowman.net> wrote: > * Robert Haas (robertmhaas@gmail.com) wrote: >> several orders of magnitude more often. That's clearly bad. On >> systems that are not too heavily loaded it doesn't matter too much >> because we just fault the page right back in from the OS pagecache. > > Ehhh. No. If it's a hot page that we've been holding in *our* cache > long enough, the kernel will happily evict it as 'cold' from *its* > cache, leading to... > >> But I've done pgbench runs where such decisions lead to long stalls, >> because the page has to be brought back in from disk, and there's a >> long I/O queue; or maybe just because the kernel thinks PostgreSQL is >> issuing too many I/O requests and makes some of them wait to cool >> things down. > > Exactly this. Yes, I believe that's why this is so effective. -- Peter Geoghegan
Commits
-
Replace the BufMgrLock with separate locks on the lookup hashtable and
- 5d5087363d7c 8.1.0 cited