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
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 |