Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id 0F6C3A8E4B6 for ; Tue, 6 Dec 2011 21:12:20 -0400 (AST) Received: from mail.anarazel.de ([217.115.131.40]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1RY63U-0007Ls-Q5 for pgsql-hackers@postgresql.org; Wed, 07 Dec 2011 01:12:20 +0000 Received: from intern.anarazel.de (g225083101.adsl.alicedsl.de [92.225.83.101]) (Authenticated sender: andres@anarazel.de) by mail.anarazel.de (Postfix) with ESMTPA id 5BB51448003; Wed, 7 Dec 2011 02:12:03 +0100 (CET) From: Andres Freund To: pgsql-hackers@postgresql.org Subject: Re: Large number of open(2) calls with bulk INSERT into empty table Date: Wed, 7 Dec 2011 02:12:00 +0100 User-Agent: KMail/1.13.7 (Linux/3.1.0-1-amd64; KDE/4.6.5; x86_64; ; ) Cc: Robert Haas , Florian Weimer References: <82ipm51tcd.fsf@mid.bfk.de> <827h29q4pd.fsf@mid.bfk.de> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201112070212.01651.andres@anarazel.de> X-Pg-Spam-Score: -3.8 (---) X-Archive-Number: 201112/291 X-Sequence-Number: 199543 On Tuesday, December 06, 2011 08:53:42 PM 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. I think if at all youre going to notice differences at a high concurrency because you then would start to hit the price of synchronizing the dcache between cpu cores in the kernel. Andres