15,000 tables - next step - Mailing list pgsql-performance

From Michael Riess
Subject 15,000 tables - next step
Date
Msg-id dmqjou$2a10$1@news.hub.org
Whole thread Raw
Responses Re: 15,000 tables - next step
List pgsql-performance
Hi,

thanks for your comments so far - I appreciate it. I'd like to narrow
down my problem a bit:

As I said in the other thread, I estimate that only 20% of the 15,000
tables are accessed regularly. So I don't think that vacuuming or the
number of file handles is a problem. Have a look at this:

content2=# select relpages, relname from pg_class order by relpages desc
limit 20;
  relpages |             relname
----------+---------------------------------
     11867 | pg_attribute
     10893 | pg_attribute_relid_attnam_index
      3719 | pg_class_relname_nsp_index
      3310 | wsobjects_types
      3103 | pg_class
      2933 | wsobjects_types_fields
      2903 | wsod_133143
      2719 | pg_attribute_relid_attnum_index
      2712 | wsod_109727
      2666 | pg_toast_98845
      2601 | pg_toast_9139566
      1876 | wsod_32168
      1837 | pg_toast_138780
      1678 | pg_toast_101427
      1409 | wsobjects_types_fields_idx
      1088 | wso_log
       943 | pg_depend
       797 | pg_depend_depender_index
       737 | wsod_3100
       716 | wp_hp_zen

I don't think that postgres was designed for a situation like this,
where a system table that should be fairly small (pg_attribute) is this
large.

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: Database restore speed
Next
From: "Luke Lonergan"
Date:
Subject: Re: Database restore speed