questions regarding shared_buffers behavior

From: Mark Rostron <mrostron(at)ql2(dot)com>
To: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: questions regarding shared_buffers behavior
Date: 2010-11-07 20:33:05
Message-ID: FD020D3E50E7FA479567872E5F5F31E3045A218A28@ex01.corp.ql2.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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 have a kernel cache, and therefore just focus on the behavior of the db cache as an isolated component, it will help - thanks in advance).

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?

Are there any particular types of *table* access operations that will cause postgres to choose not to retain the table pages in shared_buffers at the end of the operation?
In particular, the activity tracked by:

- Seq_scan

- Seq_tup_read

- Idx_tup_read

- Idx_tup_fetch

Are there any particular types of *index* access operations that will cause postgres to choose not to retain the index pages in shared_buffers at the end of the operation?
In particular, the activity tracked by:

- idx_scan

- Idx_tup_read

- Idx_tup_fetch

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Greg Smith 2010-11-07 23:30:14 Re: questions regarding shared_buffers behavior
Previous Message Robert Haas 2010-11-07 01:23:28 Re: Regression: 8.3 2 seconds -> 8.4 100+ seconds