pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
Help understanding stat numbers
2+ messages / 2 participants
[nested] [flat]

* Help understanding stat numbers
@ 2007-11-08 14:49  Chris Hoover <revoohc@gmail.com>
  0 siblings, 1 reply; 2+ messages in thread

From: Chris Hoover @ 2007-11-08 14:49 UTC (permalink / raw)
  To: pgsql-performance

I have a database where I dropped all indexes on a table last night
and built a new set of indexes.  The goal is to try and let the
database have fewer indexes and use them more.  I removed a bunch of
indexes that were surviving from our 7.3 days where functionality will
now be covered by 8.1's use of multiple indexes..

Anyway, except for the primary key, all indexes were dropped and then
the new indexes where created.  However, I am confused by what the
pg_stat_user_indexes and pg_statio_users_indexes are telling me.
Which one is correct.

pg_stat_user_indexes is reporting this:
"indexrelname","idx_scan",'idx_tup_read","idx_tup_fetch"
"clmhdr_pkey";1583576;1577152;1577027
"hdr_clm_status_partial_idx";5243;6999857;372251
"hdr_create_dt_idx";1010;1420708;3656
"hdr_user_id_idx";71;928074;918439
"hdr_pat_cntl_nbr_idx";14;42;29
"hdr_clm_type_idx";1;673982;0
"hdr_process_dt_idx";1;22050;0
"erb_hdr_create_dt_idx";0;0;0
"erb_hdr_process_dt_idx";0;0;0
"erb_hdr_stmt_from_dt_idx";0;0;0
"erb_hdr_stmt_thru_dt_idx";0;0;0
"erb_hdr_transmit_dt_idx";0;0;0
"hdr_accepted_dt_idx";0;0;0
"hdr_asc_resp_rpt_cd_idx";0;0;0
"hdr_bill_type_idx";0;0;0
"hdr_fss_clm_status_idx";0;0;0
"hdr_fss_process_dt_idx";0;0;0
"hdr_submit_mode_idx";0;0;0
"patient_name_idx";0;0;0
"statement_date_idx";0;0;0


pg_statio_user_indexes is reporting:
"indexrelname","idx_blks_read","idx_blks_hit"
"hdr_clm_status_partial_idx";182;59455
"clmhdr_pkey";115382;6540557
"erb_hdr_process_dt_idx";7943;32679
"erb_hdr_create_dt_idx";8000;32042
"erb_hdr_transmit_dt_idx";7953;31511
"erb_hdr_stmt_thru_dt_idx";8667;30924
"hdr_create_dt_idx";11988;42617
"erb_hdr_stmt_from_dt_idx";8632;30173
"hdr_fss_clm_status_idx";9920;32774
"hdr_bill_type_idx";9949;32730
"hdr_asc_resp_rpt_cd_idx";9916;32387
"hdr_clm_type_idx";11777;33130
"hdr_fss_process_dt_idx";11891;33423
"hdr_accepted_dt_idx";11913;32876
"hdr_process_dt_idx";11976;33049
"hdr_submit_mode_idx";13815;32932
"hdr_user_id_idx";17372;34188
"hdr_pat_cntl_nbr_idx";15061;29137
"statement_date_idx";18838;29834
"patient_name_idx";21619;26182



If there has been no scans on an index (as according to
pg_stat_user_indexes), why is pg_statio_user_indexes showing non 0
values in idx_blks_hit/read?

Please help me understand this apparent contradiction.

Thanks,

Chris

PG 8.1.3



^ permalink  raw  reply  [nested|flat] 2+ messages in thread

* Re: Help understanding stat numbers
@ 2007-11-09 07:08  Tom Lane <tgl@sss.pgh.pa.us>
  parent: Chris Hoover <revoohc@gmail.com>
  0 siblings, 0 replies; 2+ messages in thread

From: Tom Lane @ 2007-11-09 07:08 UTC (permalink / raw)
  To: Chris Hoover <revoohc@gmail.com>; +Cc: pgsql-performance

"Chris Hoover" <revoohc@gmail.com> writes:
> If there has been no scans on an index (as according to
> pg_stat_user_indexes), why is pg_statio_user_indexes showing non 0
> values in idx_blks_hit/read?

I grow weary, but I think that "scan" is only incremented by commencing
a SELECT search using the index, whereas the block-level counts are also
incremented when the index is modified by an insert or update.  You may
be looking at indexes that are eating update cycles but not being used
for anything important...

			regards, tom lane



^ permalink  raw  reply  [nested|flat] 2+ messages in thread


end of thread, other threads:[~2007-11-09 07:08 UTC | newest]

Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2007-11-08 14:49 Help understanding stat numbers Chris Hoover <revoohc@gmail.com>
2007-11-09 07:08 ` Tom Lane <tgl@sss.pgh.pa.us>

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox