From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Cédric Villemain <cedric(dot)villemain(dot)debian(at)gmail(dot)com> |
Cc: | Mark Rostron <mrostron(at)ql2(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: questions regarding shared_buffers behavior |
Date: | 2010-11-12 21:07:47 |
Message-ID: | AANLkTin2pkLo=gc18h1kKjMFNSLo6ARzbsQgWLyEDzCr@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Sun, Nov 7, 2010 at 10:03 PM, Cédric Villemain
<cedric(dot)villemain(dot)debian(at)gmail(dot)com> wrote:
> 2010/11/8 Mark Rostron <mrostron(at)ql2(dot)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 buffer cache 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 interested in.
>> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Jon Nelson | 2010-11-13 03:31:55 | Re: temporary tables, indexes, and query plans |
Previous Message | Robert Haas | 2010-11-12 18:57:38 | Re: anti-join chosen even when slower than old plan |