On Sun, Nov 7, 2010 at 10:03 PM, Cédric Villemain
wrote:
> 2010/11/8 Mark Rostron :
>>> >
>>> > 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 cas
2010/11/8 Mark Rostron :
>> >
>> > 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
> >
> > 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 b
Mark Rostron wrote:
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?
There is no such procedure. When a table or index page is used, its
usage count goes up, which means it's more l
Question regarding the operation of the shared_buffers cache and implications
of the pg_X_stat_tables|pg_X_stat_indexes stats.
( I am also aware that this is all complicated by the kernel cache behavior,
however, if, for the purpose of these questions, you wouldn't mind assuming
that we don't ha
