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

Re: 2nd Level Buffer Cache

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jim Nasby <jim(at)nasby(dot)net>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, rsmogura <rsmogura(at)softperience(dot)eu>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 2nd Level Buffer Cache
Date: 2011-03-24 20:59:10
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, Mar 23, 2011 at 6:12 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> It looks like the only way anything can ever get put on the free list
>> right now is if a relation or database is dropped.  That doesn't seem
>> too good.
> Why not?  AIUI the free list is only for buffers that are totally dead,
> ie contain no info that's possibly of interest to anybody.  It is *not*
> meant to substitute for running the clock sweep when you have to discard
> a live buffer.

It seems at least plausible that buffer allocation could be
significantly faster if it need only pop the head of a list, rather
than scanning until it finds a suitable candidate.  Moving as much
buffer allocation work as possible into the background seems like it
ought to be useful.

Granted, I've made no attempt to code or test this.

Robert Haas
The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

Next:From: Stephen FrostDate: 2011-03-24 21:08:02
Subject: Pre-set Hint bits/VACUUM FREEZE on data load..?
Previous:From: Radosław SmoguraDate: 2011-03-24 20:27:02
Subject: Re: 2nd Level Buffer Cache

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