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

Re: PG 8.3 and large shared buffer settings

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 (view raw, whole thread or download thread mbox)
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?




In response to


pgsql-performance by date

Next:From: Tom LaneDate: 2009-09-26 17:03:57
Subject: Re: Bad performance of SELECT ... where id IN (...)
Previous:From: Greg SmithDate: 2009-09-26 15:19:54
Subject: Re: PG 8.3 and large shared buffer settings

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