Re: Blocks read for index scans - Mailing list pgsql-performance

From Jim C. Nasby
Subject Re: Blocks read for index scans
Date
Msg-id 20060414061414.GY49405@pervasive.com
Whole thread Raw
In response to Re: Blocks read for index scans  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Blocks read for index scans  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
On Thu, Apr 13, 2006 at 08:36:09PM -0400, Tom Lane wrote:
> Jim Nasby <jnasby@pervasive.com> writes:
> > While working on determining a good stripe size for a database, I
> > realized it would be handy to know what the average request size is.
> > Getting this info is a simple matter of joining pg_stat_all_tables
> > and pg_statio_all_tables and doing some math, but there's one issue
> > I've found; it appears that there's no information on how many heap
> > blocks were read in by an index scan. Is there any way to get that info?
>
> If the table is otherwise idle, the change in the table's entry in
> pgstatio_all_tables should do, no?

Ahh, ok, I see the heap blocks are counted. So I guess if you wanted to
know what the average number of blocks read from the heap per request
was you'd have to do heap_blks_read / ( seq_scan + idx_scan ), with the
last two comming from pg_stat_all_tables.

In my case it would be helpful to break the heap access numbers out
between seqscans and index scans, since each of those represents very
different access patterns. Would adding that be a mess?

> (This is as of 8.1 ... older versions acted a bit differently IIRC.)

Yeah; I recall that it was pretty confusing exactly how things were
broken out and that you changed it as part of the bitmap scan work.
--
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461

pgsql-performance by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: Inserts optimization?
Next
From: "Jim C. Nasby"
Date:
Subject: Re: pg 7.4.x - pg_restore impossibly slow