pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Bruce Momjian <bruce@momjian.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Florian Weimer <fweimer@bfk.de>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Large number of open(2) calls with bulk INSERT into empty table
Date: Thu, 16 Aug 2012 21:05:24 -0400
Message-ID: <20120817010524.GL30286@momjian.us> (raw)
In-Reply-To: <CA+TgmobRiGQH+GNC+vTmEf=AgknBirSEUy3PFg4MzpXTXmfLqQ@mail.gmail.com>
References: <82ipm51tcd.fsf@mid.bfk.de>
	<CA+TgmoYRGO5Wu4_2yzP0-cmx4GBZHqOO4WKiCxT-R3gV6qrt6A@mail.gmail.com>
	<827h29q4pd.fsf@mid.bfk.de>
	<CA+TgmobRiGQH+GNC+vTmEf=AgknBirSEUy3PFg4MzpXTXmfLqQ@mail.gmail.com>


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 <fweimer@bfk.de> 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  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +




view thread (17+ messages)  latest in thread

Message-ID: <20120817010524.GL30286@momjian.us>
Permalink:  ../20120817010524.GL30286@momjian.us/
Also on:    postgresql.org/message-id/20120817010524.GL30286@momjian.us

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: bruce@momjian.us, robertmhaas@gmail.com, fweimer@bfk.de
  Subject: Re: Large number of open(2) calls with bulk INSERT into empty table
  In-Reply-To: <20120817010524.GL30286@momjian.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox