Received: from makus.postgresql.org ([98.129.198.125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1T2B0F-0007M2-HS for pgsql-hackers@postgresql.org; Fri, 17 Aug 2012 01:05:31 +0000 Received: from momjian.us ([72.94.173.45]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1T2B0D-0008MC-LR for pgsql-hackers@postgresql.org; Fri, 17 Aug 2012 01:05:30 +0000 Received: from bruce by momjian.us with local (Exim 4.72) (envelope-from ) id 1T2B08-0005ug-L6; Thu, 16 Aug 2012 21:05:24 -0400 Date: Thu, 16 Aug 2012 21:05:24 -0400 From: Bruce Momjian To: Robert Haas Cc: Florian Weimer , pgsql-hackers@postgresql.org Subject: Re: Large number of open(2) calls with bulk INSERT into empty table Message-ID: <20120817010524.GL30286@momjian.us> References: <82ipm51tcd.fsf@mid.bfk.de> <827h29q4pd.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201208/457 X-Sequence-Number: 212278 A TODO for this? --------------------------------------------------------------------------- On Tue, Dec 6, 2011 at 02:53:42PM -0500, Robert Haas wrote: > On Tue, Dec 6, 2011 at 7:12 AM, Florian Weimer wrote: > > * Robert Haas: > > > >> I tried whacking out the call to GetPageWithFreeSpace() in > >> RelationGetBufferForTuple(), and also with the unpatched code, but the > >> run-to-run randomness was way more than any difference the change > >> made.  Is there a better test case? > > > > I think that if you want to exercise file system lookup performance, you > > need a larger directory, which presumably means a large number of > > tables. > > OK. I created 100,000 dummy tables, 10,000 at a time avoid blowing up > the lock manager. I then repeated my previous tests, and I still > can't see any meaningful difference (on my MacBook Pro, running MacOS > X v10.6.8). So at least on this OS, it doesn't seem to matter much. > I'm inclined to defer putting any more work into it until such time as > someone can demonstrate that it actually causes a problem and provides > a reproducible test case. I don't deny that there's probably an > effect and it would be nice to improve this, but it doesn't seem worth > spending a lot of time on until we can find a case where the effect is > measurable. > > On the other hand, the problem of the FSM taking up 24kB for an 8kB > table seems clearly worth fixing, but I don't think I have the cycles > for it at present. Maybe a TODO is in order. > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +