| 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: | AANLkTiktwL=AUCucv6=VqVzfx+AP8hxf8g-eYoa1NMP1@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2011-03-24 21:08:02 | Pre-set Hint bits/VACUUM FREEZE on data load..? |
| Previous Message | Radosław Smogura | 2011-03-24 20:27:02 | Re: 2nd Level Buffer Cache |