Re: [PERFORM] Blocks read for index scans

2006-04-18 Thread Mark Kirkwood
Jim C. Nasby wrote: Yeah... not gonna happen... It's completely mind-boggling that FBSD doesn't track writes and reads seperately. 'iostat' does not tell you this, but 'gstat' does - its the "geom" system monitor (a bit annoying that the standard tool is lacking in this regard...). Cheer

Re: [PERFORM] Blocks read for index scans

2006-04-18 Thread Jim C. Nasby
On Wed, Apr 19, 2006 at 04:35:11AM +0200, Terje Elde wrote: > Jim C. Nasby wrote: > >>That said, it's the transactions against disk that typically matter. On > >>FreeBSD, you can get an impression of this using 'systat -vmstat', and > >>watch the KB/t column for your drives. > >> > > > >On a

Re: [PERFORM] Blocks read for index scans

2006-04-18 Thread Terje Elde
Jim C. Nasby wrote: That said, it's the transactions against disk that typically matter. On FreeBSD, you can get an impression of this using 'systat -vmstat', and watch the KB/t column for your drives. On a related note, you know of any way to determine the breakdown between read activit

Re: [PERFORM] Blocks read for index scans

2006-04-18 Thread Jim C. Nasby
On Fri, Apr 14, 2006 at 08:05:39AM +0200, Terje Elde wrote: > Jim Nasby wrote: > >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 >

Re: [PERFORM] Blocks read for index scans

2006-04-18 Thread Jim C. Nasby
On Fri, Apr 14, 2006 at 11:12:55AM -0400, Tom Lane wrote: > "Jim C. Nasby" <[EMAIL PROTECTED]> writes: > > 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 b

Re: [PERFORM] Blocks read for index scans

2006-04-14 Thread Tom Lane
"Jim C. Nasby" <[EMAIL PROTECTED]> writes: > 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? Yes; it'd require more counters-per-table than we now k

Re: [PERFORM] Blocks read for index scans

2006-04-13 Thread Terje Elde
Jim Nasby wrote: 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 fo

Re: [PERFORM] Blocks read for index scans

2006-04-13 Thread Jim C. Nasby
On Thu, Apr 13, 2006 at 08:36:09PM -0400, Tom Lane wrote: > Jim Nasby <[EMAIL PROTECTED]> 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

Re: [PERFORM] Blocks read for index scans

2006-04-13 Thread Tom Lane
Jim Nasby <[EMAIL PROTECTED]> 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,

Re: [PERFORM] Blocks read for index scans

2006-04-13 Thread Jim Nasby
Adding -performance back in... > From: Steve Poe [mailto:[EMAIL PROTECTED] > Jim, > > I could be way off, but doesn't from pg_statio_user_tables > contain this > information? http://www.postgresql.org/docs/8.1/interactive/monitoring-stats.html#MONITORING-STATS-VIEWS states: "numbers of disk b

[PERFORM] Blocks read for index scans

2006-04-13 Thread Jim Nasby
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 appear