DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=Yahoo.com;
	h=Received:Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=nNPnJJspszS1CYM5uDXzhM5ENDdumtZn2mYHM21rYoRAo9Z1CNaKu4UsYuCnB0jvsyWhm7o+4sFw/4GRJ6w1+dSrHmE6M3IBTy1d5DxK0LthQ76jFSsizlQ1H3OrpmIRE11TMY5epc4uzOg23S//hFBRSYzWb+TCz1MphczoYMY=
	;
Message-ID: <4391BF0F.9000208@Yahoo.com>
Date: Sat, 03 Dec 2005 10:51:43 -0500
From: Jan Wieck <JanWieck@Yahoo.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.1) Gecko/20040707
MIME-Version: 1.0
To: Michael Riess <mlriess@gmx.de>
CC: pgsql-performance@postgresql.org
Subject: Re: 15,000 tables - next step
References: <dmqjou$2a10$1@news.hub.org>
In-Reply-To: <dmqjou$2a10$1@news.hub.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

On 12/2/2005 6:01 PM, Michael Riess wrote:

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

What makes you think that? Have you at least tried to adjust your shared 
buffers, freespace map settings and background writer options to values 
that match your DB? How does increasing the kernel file desctriptor 
limit (try the current limit times 5 or 10) affect your performance?


Jan


> 
> 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.
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match


-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #