15,000 tables - next step

From: Michael Riess <mlriess(at)gmx(dot)de>
To: pgsql-performance(at)postgresql(dot)org
Subject: 15,000 tables - next step
Date: 2005-12-02 23:01:55
Message-ID: dmqjou$2a10$1@news.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Luke Lonergan 2005-12-02 23:02:11 Re: Database restore speed
Previous Message Tom Lane 2005-12-02 23:00:59 Re: Database restore speed