On Thu, Aug 09, 2007 at 09:14:55PM -0400, Steve Madsen wrote: > On Aug 8, 2007, at 6:08 PM, Decibel! wrote: > >Something else I like to look at is pg_stat_all_tables seq_scan and > >seq_tup_read. If seq_scan is a large number and seq_tup_read/ > >seq_scan is > >also large, that indicates that you could use an index on that table. > > If seq_tup_read / seq_scan is large relative to the number of rows in > the table, wouldn't that imply that those sequential scans are often > returning most of the rows in the table? In that case, would an > index help much or is a sequential scan the expected result? I can't really think of a case where a seqscan wouldn't return all the rows in the table... that's what it's meant to do. What I was driving at by looking at seq_tup_read is that a small table isn't going to use indexes anyway, so for the small tables it's generally not worth worrying about indexes. If you wanted to be more accurate you could look at reltuples or maybe relpages in pg_class instead. -- Decibel!, aka Jim Nasby decibel@xxxxxxxxxxx EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
Attachment:
pgpuEY7uzx7CU.pgp
Description: PGP signature
