From: | Cédric Villemain <cedric(dot)villemain(dot)debian(at)gmail(dot)com> |
---|---|
To: | chirag(dot)dave(at)gmail(dot)com |
Cc: | Balkrishna Sharma <b_ki(at)hotmail(dot)com>, pgsql-admin(at)postgresql(dot)org |
Subject: | Re: How to find if a SELECT is reading from buffer or disk ? |
Date: | 2010-05-26 09:25:59 |
Message-ID: | AANLkTilRPVq_yVQuUyB_fH9QAk6QlpQlbcOIzichQWF8@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
2010/5/25 Chirag Dave <cdave(at)ca(dot)afilias(dot)info>:
>
>
> On Tue, May 25, 2010 at 1:48 PM, Balkrishna Sharma <b_ki(at)hotmail(dot)com> wrote:
>>
>> Hi,
>> I am increasing the shared_buffer size in postgresql.conf and want to
>> measure its effect on READ. In essence I want to know if the SELECT queries
>> I am firing repeatedly is reading from the buffer or going directly to the
>> disk.
>> I am expecting the first SELECT to go to disk and the subsequent call of
>> the same SELECT to read from buffer .
>> Right now I am just looking at execution time of the SELECTs and trying to
>> conclude. But there should be a direct way to see where the SELECT reads
>> from.
>
> You can also use pg_stat_database view. you can compute cache reads
> percentage of the total number of reads (cache and physical) between the two
> snapshots using pg_stat_database.blks_hit and pg_stat_database.blks_read.
views does not reflect this exact behavior : hit and read are relative
to hit shared buffers and request a block (from OS page cache or from
disk).
>
> Chirag Dave 416-673-4102
> Database Administrator, Afilias Canada Corp.
> cdave(at)ca(dot)afilias(dot)info
>
>
>>
>> How can I accomplish this ?
>> Thanks
>> Bala
>> ________________________________
>> The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with
>> Hotmail. Get busy.
>
--
Cédric Villemain 2ndQuadrant
http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support
From | Date | Subject | |
---|---|---|---|
Next Message | Ravi Katkar | 2010-05-26 10:35:11 | Transaction with in function |
Previous Message | Simon Riggs | 2010-05-26 06:28:53 | Re: could not truncate directory "pg_subtrans": apparent wraparound |