Re: questions regarding shared_buffers behavior - Mailing list pgsql-performance

From Robert Haas
Subject Re: questions regarding shared_buffers behavior
Date
Msg-id AANLkTin2pkLo=gc18h1kKjMFNSLo6ARzbsQgWLyEDzCr@mail.gmail.com
Whole thread Raw
In response to Re: questions regarding shared_buffers behavior  (Cédric Villemain <cedric.villemain.debian@gmail.com>)
List pgsql-performance
On Sun, Nov 7, 2010 at 10:03 PM, Cédric Villemain
<cedric.villemain.debian@gmail.com> wrote:
> 2010/11/8 Mark Rostron <mrostron@ql2.com>:
>>> >
>>> > What is the procedure that postgres uses to decide whether or not a
>>> > table/index block will be left in the shared_buffers cache at the end
>>> > of the operation?
>>> >
>>>
>>> The only special cases are for sequential scans and VACUUM, which use continuously re-use a small section of the
buffercache in some cases instead. 
>>
>> Thanks - the part about sequential scans and the re-use of a small section of shared_buffers is the bit I was
interestedin. 
>> I don't suppose you would be able to tell me how large that re-useable area might be?
>
> There are 256KB per seqscan and 256KB per vacuum.
>
> I suggest you to go reading src/backend/storage/buffer/README

Note that there is a different, higher limit for the "bulk write"
strategy when using COPY IN or CTAS.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

pgsql-performance by date:

Previous
From: Robert Haas
Date:
Subject: Re: anti-join chosen even when slower than old plan
Next
From: "静安寺"
Date:
Subject: Re: Why dose the planner select one bad scan plan.