Re: Large number of open(2) calls with bulk INSERT into empty table

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Florian Weimer <fweimer(at)bfk(dot)de>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Large number of open(2) calls with bulk INSERT into empty table
Date: 2011-11-30 17:29:47
Message-ID: 23238.1322674187@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sun, Nov 27, 2011 at 10:24 AM, Florian Weimer <fweimer(at)bfk(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Abbate 2011-11-30 17:36:27 Re: Reserved words and delimited identifiers
Previous Message Robert Haas 2011-11-30 17:23:50 Re: Large number of open(2) calls with bulk INSERT into empty table