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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Large number of open(2) calls with bulk INSERT into empty table
Дата
Msg-id 23238.1322674187@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Large number of open(2) calls with bulk INSERT into empty table  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Large number of open(2) calls with bulk INSERT into empty table  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Large number of open(2) calls with bulk INSERT into empty table
Следующее
От: Joe Abbate
Дата:
Сообщение: Re: Reserved words and delimited identifiers