From: | Gerhard Wiesinger <lists(at)wiesinger(dot)com> |
---|---|
To: | Greg Smith <gsmith(at)gregsmith(dot)com> |
Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Scott Carey <scott(at)richrelevance(dot)com>, Aidan Van Dyk <aidan(at)highrise(dot)ca>, Dan Sugalski <dan(at)sidhe(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: PG 8.3 and large shared buffer settings |
Date: | 2009-09-26 16:57:35 |
Message-ID: | alpine.LFD.2.00.0909261854410.11991@bbs.intern |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Sat, 26 Sep 2009, Greg Smith wrote:
> On Fri, 25 Sep 2009, Jeff Janes wrote:
>
>> Does it do this even if the block was already in shared_buffers?
>
> Usually not. The buffer ring algorithm is used to manage pages that are read
> in specifically to satisfy a sequential scan (there's a slightly different
> ring method used for VACUUM too). If the buffer you need is already
> available and not "pinned" (locked by someone else), it's not read from disk
> again. Instead, its usage count is incremently only if it's at zero (this
> doesn't count as a use unless it's about to be evicted as unused), and it's
> returned without being added to the ring.
>
Hello Greg,
What happens when a postmaster dies (e.g. core dump, kill -9, etc.). How
is reference counting cleaned up and the lock removed?
Thnx.
Ciao,
Gerhard
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-09-26 17:03:57 | Re: Bad performance of SELECT ... where id IN (...) |
Previous Message | Greg Smith | 2009-09-26 15:19:54 | Re: PG 8.3 and large shared buffer settings |