pg.ddx.io pgsql-admin@postgresql.org mailing list archive
help / color / mirror / Atom feedpg_* Tables
3+ messages / 2 participants
[nested] [flat]
* pg_* Tables
@ 2010-12-06 02:40 Samuel Stearns <SStearns@internode.com.au>
2010-12-06 07:03 ` Re: pg_* Tables Greg Williamson <gwilliamson39@yahoo.com>
0 siblings, 1 reply; 3+ messages in thread
From: Samuel Stearns @ 2010-12-06 02:40 UTC (permalink / raw)
To: pgsql-admin
Howdy,
Environment:
Solaris 10
Postgres 8.3.3
I'm getting high sequential scans for some pg_* tables:
<database>=# select relname, sum(seq_scan) as seq_scan,sum(seq_tup_read) as seq_tup_read,sum(idx_scan) as idx_scan, sum(idx_tup_fetch) as idx_tup_fetch, sum(n_tup_ins) as n_tup_ins, sum(n_tup_upd) as n_tup_upd, sum(n_tup_del) as n_tup_del from pg_stat_all_tables group by 1 order by 2 desc limit 4;
relname | seq_scan | seq_tup_read | idx_scan | idx_tup_fetch | n_tup_ins | n_tup_upd | n_tup_del
---------------------------------+----------+--------------+----------+---------------+-----------+-----------+-----------
<table> | 6896498 | 91295702 | 107663 | 469057 | 103966 | 103966 | 103966
pg_authid | 3119053 | 125950392 | 12000732 | 12000718 | 1 | 1 | 0
pg_am | 2642438 | 2642440 | 5 | 5 | 0 | 0 | 0
pg_database | 1349020 | 14771768 | 6953392 | 6953392 | 0 | 0 | 0
(4 rows)
<database>=#
Is this normal? Is it advisable to index pg_* tables?
Thank you,
Sam
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: pg_* Tables
2010-12-06 02:40 pg_* Tables Samuel Stearns <SStearns@internode.com.au>
@ 2010-12-06 07:03 ` Greg Williamson <gwilliamson39@yahoo.com>
2010-12-07 03:21 ` Re: pg_* Tables Samuel Stearns <SStearns@internode.com.au>
0 siblings, 1 reply; 3+ messages in thread
From: Greg Williamson @ 2010-12-06 07:03 UTC (permalink / raw)
To: Samuel Stearns <SStearns@internode.com.au>; pgsql-admin
Samuel Stearns wrote:
>> Howdy,
>>
>> Environment:
>>
>> Solaris 10
>> Postgres 8.3.3
>>
>> I’m getting high sequential scans for some pg_* tables:
>>
>> <database>=# select relname, sum(seq_scan) as seq_scan,sum(seq_tup_read)
>> as seq_tup_read,sum(idx_scan) as idx_scan, sum(idx_tup_fetch) as
>idx_tup_fetch,
>> sum(n_tup_ins) as n_tup_ins, sum(n_tup_upd) as n_tup_upd, sum(n_tup_del) as
>>n_tup_del
>> from pg_stat_all_tables group by 1 order by 2 desc limit 4;
>> relname | seq_scan | seq_tup_read | idx_scan |
>>idx_tup_fetch | n_tup_ins | n_tup_upd | n_tup_del
>>---------------------------------+----------+--------------+----------+---------------+-----------+-----------+-----------
>>-
>> <table> | 6896498 | 91295702 | 107663 | 469057 | 103966 |
>>103966 | 103966
>> pg_authid | 3119053 | 125950392 | 12000732 |
>>12000718 | 1 | 1 | 0
>> pg_am | 2642438 | 2642440 | 5
>>| 5 | 0 | 0 | 0
>> pg_database | 1349020 | 14771768 | 6953392 |
>>6953392 | 0 | 0 | 0<...>
>> Is this normal? Is it advisable to index pg_* tables?
Do you vacuum the database regularly ?
What are the number of rows in those tables ?
It is possible that the planner is doing a sequential scan because the tables
are small and that's faster than doing indexed reads.
Greg Williamson
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: pg_* Tables
2010-12-06 02:40 pg_* Tables Samuel Stearns <SStearns@internode.com.au>
2010-12-06 07:03 ` Re: pg_* Tables Greg Williamson <gwilliamson39@yahoo.com>
@ 2010-12-07 03:21 ` Samuel Stearns <SStearns@internode.com.au>
0 siblings, 0 replies; 3+ messages in thread
From: Samuel Stearns @ 2010-12-07 03:21 UTC (permalink / raw)
To: Greg Williamson <gwilliamson39@yahoo.com>; pgsql-admin
Yep, small row counts. Thanks, Greg!
From: Greg Williamson [mailto:gwilliamson39@yahoo.com]
Sent: Monday, 6 December 2010 5:34 PM
To: Samuel Stearns; pgsql-admin@postgresql.org
Subject: Re: [ADMIN] pg_* Tables
Samuel Stearns wrote:
>> Howdy,
>>
>> Environment:
>>
>> Solaris 10
>> Postgres 8.3.3
>>
>> I’m getting high sequential scans for some pg_* tables:
>>
>> <database>=# select relname, sum(seq_scan) as seq_scan,sum(seq_tup_read)
>> as seq_tup_read,sum(idx_scan) as idx_scan, sum(idx_tup_fetch) as idx_tup_fetch,
>> sum(n_tup_ins) as n_tup_ins, sum(n_tup_upd) as n_tup_upd, sum(n_tup_del) as n_tup_del
>> from pg_stat_all_tables group by 1 order by 2 desc limit 4;
>> relname | seq_scan | seq_tup_read | idx_scan | idx_tup_fetch | n_tup_ins | n_tup_upd | n_tup_del
>> ---------------------------------+----------+--------------+----------+---------------+-----------+-----------+-----------
>> <table> | 6896498 | 91295702 | 107663 | 469057 | 103966 | 103966 | 103966
>> pg_authid | 3119053 | 125950392 | 12000732 | 12000718 | 1 | 1 | 0
>> pg_am | 2642438 | 2642440 | 5 | 5 | 0 | 0 | 0
>> pg_database | 1349020 | 14771768 | 6953392 | 6953392 | 0 | 0 | 0
<...>
>> Is this normal? Is it advisable to index pg_* tables?
Do you vacuum the database regularly ?
What are the number of rows in those tables ?
It is possible that the planner is doing a sequential scan because the tables are small and that's faster than doing indexed reads.
Greg Williamson
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2010-12-07 03:21 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2010-12-06 02:40 pg_* Tables Samuel Stearns <SStearns@internode.com.au>
2010-12-06 07:03 ` Greg Williamson <gwilliamson39@yahoo.com>
2010-12-07 03:21 ` Samuel Stearns <SStearns@internode.com.au>
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