pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedImproving performance on system catalog
6+ messages / 4 participants
[nested] [flat]
* Improving performance on system catalog
@ 2007-03-28 12:59 Daniel Cristian Cruz <danielcristian@gmail.com>
0 siblings, 2 replies; 6+ messages in thread
From: Daniel Cristian Cruz @ 2007-03-28 12:59 UTC (permalink / raw)
To: pgsql-performance
Hi all.
I would like to speed up this query:
EXPLAIN ANALYZE
SELECT
relid,schemaname,relname,seq_scan,seq_tup_read,idx_scan,idx_tup_fetch,n_tup_ins,n_tup_upd,n_tup_del
FROM pg_stat_user_tables;
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------
Subquery Scan pg_stat_all_tables (cost=747.72..791.10 rows=195 width=236)
(actual time=11.582..13.632 rows=200 loops=1)
-> HashAggregate (cost=747.72..752.10 rows=195 width=136) (actual time=
11.571..12.813 rows=200 loops=1)
-> Hash Join (cost=209.32..745.28 rows=195 width=136) (actual
time=1.780..6.477 rows=453 loops=1)
Hash Cond: ("outer".relnamespace = "inner".oid)
-> Hash Left Join (cost=206.87..702.69 rows=227 width=76)
(actual time=1.729..5.392 rows=507 loops=1)
Hash Cond: ("outer".oid = "inner".indrelid)
-> Seq Scan on pg_class c (cost=0.00..465.22 rows=227
width=72) (actual time=0.013..2.552 rows=228 loops=1)
Filter: (relkind = 'r'::"char")
-> Hash (cost=205.40..205.40 rows=587 width=8)
(actual time=1.698..1.698 rows=0 loops=1)
-> Seq Scan on pg_index i
(cost=0.00..205.40rows=587 width=8) (actual time=
0.004..1.182 rows=593 loops=1)
-> Hash (cost=2.44..2.44 rows=6 width=68) (actual time=
0.035..0.035 rows=0 loops=1)
-> Seq Scan on pg_namespace n (cost=0.00..2.44 rows=6
width=68) (actual time=0.013..0.028 rows=6 loops=1)
Filter: ((nspname <> 'pg_catalog'::name) AND
(nspname <> 'pg_toast'::name))
Total runtime: 13.844 ms
I think there would be good to create an index on pg_class.relkind and
pg_class.relnamespace, but its impossible since its a catalog table.
Any way to make it a default index (system index)?
Its an old PostgreSQL server:
SELECT version();
version
------------------------------------------------------------------------------------------------------------------------------
PostgreSQL 7.4.13 on x86_64-redhat-linux-gnu, compiled by GCC
x86_64-redhat-linux-gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-2)
--
Daniel Cristian Cruz
Analista de Sistemas
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Improving performance on system catalog
@ 2007-03-28 13:24 chris smith <dmagick@gmail.com>
parent: Daniel Cristian Cruz <danielcristian@gmail.com>
1 sibling, 1 reply; 6+ messages in thread
From: chris smith @ 2007-03-28 13:24 UTC (permalink / raw)
To: Daniel Cristian Cruz <danielcristian@gmail.com>; +Cc: pgsql-performance
> I would like to speed up this query:
<snip>
> Total runtime: 13.844 ms
Why bother?
It's running in less than 14 milliseconds.
--
Postgresql & php tutorials
http://www.designmagick.com/
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Improving performance on system catalog
@ 2007-03-28 15:52 Daniel Cristian Cruz <danielcristian@gmail.com>
parent: chris smith <dmagick@gmail.com>
0 siblings, 1 reply; 6+ messages in thread
From: Daniel Cristian Cruz @ 2007-03-28 15:52 UTC (permalink / raw)
To: ; +Cc: pgsql-performance
2007/3/28, chris smith <dmagick@gmail.com>:
>
> > Total runtime: 13.844 ms
>
> Why bother?
Because faster could be better in a very busy system.
--
Daniel Cristian Cruz
Analista de Sistemas
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Improving performance on system catalog
@ 2007-03-28 15:57 Joshua D. Drake <jd@commandprompt.com>
parent: Daniel Cristian Cruz <danielcristian@gmail.com>
1 sibling, 0 replies; 6+ messages in thread
From: Joshua D. Drake @ 2007-03-28 15:57 UTC (permalink / raw)
To: Daniel Cristian Cruz <danielcristian@gmail.com>; +Cc: pgsql-performance
Daniel Cristian Cruz wrote:
> Hi all.
>
> I would like to speed up this query:
>
> EXPLAIN ANALYZE
> SELECT
> relid,schemaname,relname,seq_scan,seq_tup_read,idx_scan,idx_tup_fetch,n_tup_ins,n_tup_upd,n_tup_del
>
> FROM pg_stat_user_tables;
>
Although optimizing for 13ms is a little silly imo, you could probably
gain from calling the specific query underneath instead of calling the
view pg_stat_user_tables.
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Improving performance on system catalog
@ 2007-03-28 16:28 Tom Lane <tgl@sss.pgh.pa.us>
parent: Daniel Cristian Cruz <danielcristian@gmail.com>
0 siblings, 1 reply; 6+ messages in thread
From: Tom Lane @ 2007-03-28 16:28 UTC (permalink / raw)
To: Daniel Cristian Cruz <danielcristian@gmail.com>; +Cc: pgsql-performance
"Daniel Cristian Cruz" <danielcristian@gmail.com> writes:
> 2007/3/28, chris smith <dmagick@gmail.com>:
>>> Total runtime: 13.844 ms
>>
>> Why bother?
> Because faster could be better in a very busy system.
If you are concerned about global performance improvement, quit worrying
about this micro-detail and get yourself onto a more modern Postgres.
regards, tom lane
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Improving performance on system catalog
@ 2007-03-28 17:08 Daniel Cristian Cruz <danielcristian@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 6+ messages in thread
From: Daniel Cristian Cruz @ 2007-03-28 17:08 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-performance
2007/3/28, Tom Lane <tgl@sss.pgh.pa.us>:
>
> "Daniel Cristian Cruz" <danielcristian@gmail.com> writes:
> > 2007/3/28, chris smith <dmagick@gmail.com>:
> >>> Total runtime: 13.844 ms
> >>
> >> Why bother?
>
> > Because faster could be better in a very busy system.
>
> If you are concerned about global performance improvement, quit worrying
> about this micro-detail and get yourself onto a more modern Postgres.
Got it. We just planned move to 8.2.3 in about two weeks.
--
Daniel Cristian Cruz
Analista de Sistemas
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2007-03-28 17:08 UTC | newest]
Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2007-03-28 12:59 Improving performance on system catalog Daniel Cristian Cruz <danielcristian@gmail.com>
2007-03-28 13:24 ` chris smith <dmagick@gmail.com>
2007-03-28 15:52 ` Daniel Cristian Cruz <danielcristian@gmail.com>
2007-03-28 16:28 ` Tom Lane <tgl@sss.pgh.pa.us>
2007-03-28 17:08 ` Daniel Cristian Cruz <danielcristian@gmail.com>
2007-03-28 15:57 ` Joshua D. Drake <jd@commandprompt.com>
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