Обсуждение: Improving performance on system catalog

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.40 rows=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

> 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/

2007/3/28, chris smith <dmagick@gmail.com>:
--
Daniel Cristian Cruz
Analista de Sistemas

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/

"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

2007/3/28, Tom Lane <tgl@sss.pgh.pa.us>:
--
Daniel Cristian Cruz
Analista de Sistemas