Skip site navigation (1) Skip section navigation (2)

Re: [PERFORM] stats on cursor and query execution troubleshooting

From: "Alban Médici (NetCentrex)" <amedici(at)fr(dot)netcentrex(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-benchmarks(at)postgresql(dot)org, pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] stats on cursor and query execution troubleshooting
Date: 2004-10-08 08:47:42
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-benchmarkspgsql-performance
Thanks for your repply,  but I still don"t understand why the statistic 
logs   :

!       0/0 [0/0] filesystem blocks in/out

it told me there is no hard disk access, I'm sure there is,  I heard my 
HDD,  and see activity using gkrellm (even using my first query ; big 
select *) ?

2004-10-08 10:40:05 DEBUG:  query: select * from "LINE_Line";
2004-10-08 10:40:53 DEBUG:  QUERY STATISTICS
! system usage stats:
!       48.480196 elapsed 42.010000 user 0.700000 system sec
!       [42.030000 user 0.720000 sys total]
!       0/0 [0/0] filesystem blocks in/out
!       6/23 [294/145] page faults/reclaims, 0 [0] swaps
!       0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent
!       0/0 [0/0] voluntary/involuntary context switches
! postgres usage stats:
!       Shared blocks:       3902 read,          0 written, buffer hit 
rate = 11.78%
!       Local  blocks:          0 read,          0 written, buffer hit 
rate = 0.00%
!       Direct blocks:          0 read,          0 written

looking at the web some logs,  I saw those fields filled (i/o filesystem)
Does my postgresql.conf missing an option or is therer a known bug of my 
postgresql server  7.2.4 ?


Alban Médici

on 06/10/2004 16:16 Tom Lane said the following:

>=?ISO-8859-1?Q?=22Alban_M=E9dici_=28NetCentrex=29=22?= <amedici(at)fr(dot)netcentrex(dot)net> writes:
>>I'm looking for the statistic of memory,  CPU,  filesystem access while=20
>>executing some regular SQL query,  and I want to compare them to
>>same kind of results while executing a cursor function.
>I think your second query is finding all the disk pages it needs in
>kernel disk cache, because they were all read in by the first query.
>This has little to do with cursor versus non cursor, and everything
>to do with hitting recently-read data again.
>			regards, tom lane

Alban Médici
R&D software engineer
you can contact me @ :

In response to


pgsql-performance by date

Next:From: Pierre-Frédéric CaillaudDate: 2004-10-08 08:54:59
Subject: Re: sequential scan on select distinct
Previous:From: Josh BerkusDate: 2004-10-08 05:53:26
Subject: Re: Data warehousing requirements

pgsql-benchmarks by date

Next:From: Tom LaneDate: 2004-10-08 13:55:56
Subject: Re: [PERFORM] stats on cursor and query execution troubleshooting
Previous:From: Tom LaneDate: 2004-10-06 14:16:39
Subject: Re: [PERFORM] stats on cursor and query execution troubleshooting

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group