To: Jeff Davis <pgsql@j-davis.com>
cc: "Joshua D. Drake" <jd@commandprompt.com>, CAJ CAJ <pguser@gmail.com>,
	Ralph Mason <ralph.mason@telogis.com>, pgsql-performance@postgresql.org
Subject: Re: Performance Woes 
In-reply-to: <1178757739.24902.78.camel@dogma.v10.wvs> 
References: <5132236932388612597@unknownmsgid>
	<467669b30705091726j31fce52fp2f49649be675d811@mail.gmail.com>
	<4642677F.80209@commandprompt.com>
	<1178757739.24902.78.camel@dogma.v10.wvs>
Comments: In-reply-to Jeff Davis <pgsql@j-davis.com>
	message dated "Wed, 09 May 2007 17:42:19 -0700"
Date: Thu, 10 May 2007 00:30:04 -0400
Message-ID: <6685.1178771404@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Jeff Davis <pgsql@j-davis.com> writes:
> On Wed, 2007-05-09 at 17:29 -0700, Joshua D. Drake wrote:
>> Sounds to me like you just need to up the total amount of open files 
>> allowed by the operating system.

> It looks more like the opposite, here's the docs for
> max_files_per_process:

I think Josh has got the right advice.  The manual is just saying that
you can reduce max_files_per_process to avoid the failure, but it's not
making any promises about the performance penalty for doing that.
Apparently Ralph's app needs a working set of between 800 and 1000 open
files to have reasonable performance.

> That is a lot of tables. Maybe a different OS will handle it better?
> Maybe there's some way that you can use fewer connections and then the
> OS could still handle it?

Also, it might be worth rethinking the database structure to reduce the
number of tables.  But for a quick-fix, increasing the kernel limit
seems like the easiest answer.

			regards, tom lane