Re: Large number of open(2) calls with bulk INSERT into empty table - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Large number of open(2) calls with bulk INSERT into empty table
Date
Msg-id 23238.1322674187@sss.pgh.pa.us
Whole thread Raw
In response to Re: Large number of open(2) calls with bulk INSERT into empty table  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Large number of open(2) calls with bulk INSERT into empty table
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, Nov 27, 2011 at 10:24 AM, Florian Weimer <fweimer@bfk.de> wrote:
>> I noticed that a bulk INSERT into an empty table (which has been
>> TRUNCATEd in the same transaction, for good measure) results in a
>> curious number of open(2) calls for the FSM resource fork:

> That's kind of unfortunate.  It looks like every time we extend the
> relation, we try to read the free space map to see whether there's a
> block available with free space in it.  But since we never actually
> make any entries in the free space map, the fork never gets created,
> so every attempt to read it involves a system call to see whether it's
> there.

I wonder whether it'd help if we went ahead and created the FSM file,
with length zero, as soon as the relation is made (or maybe when it
first becomes of nonzero length).  That would at least save the failed
open()s.  We'd still be doing lseeks on the FSM file, but those ought
to be cheaper.

A less shaky way to do it would be to just create the first page of the
FSM file immediately, but that would represent an annoying percentage
increase in the disk space needed for small tables.  Or maybe we could
compromise and do that once the rel reaches N pages, for some N.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Large number of open(2) calls with bulk INSERT into empty table
Next
From: Joe Abbate
Date:
Subject: Re: Reserved words and delimited identifiers