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: Bruce Momjian <bruce(at)momjian(dot)us>, 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: 2012-08-20 22:44:01
Message-ID: 11360.1345502641@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 Mon, Aug 20, 2012 at 4:27 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Surely we could just prevent creation of the FSM until the table has
>> reached at least, say, 10 blocks.
>>
>> Any threshold beyond one block would mean potential space wastage,
>> but it's hard to get excited about that until you're into the dozens
>> of pages.

> I dunno, I think one-row tables are pretty common.

Sure, and for that you don't need an FSM, because any row allocation
attempt will default to trying the last existing block before it extends
(see RelationGetBufferForTuple). It's only once you've got more than
one block in the table that it becomes interesting.

If we had a convention that FSM is only created for rels of more than
N blocks, perhaps it'd be worthwhile to teach RelationGetBufferForTuple
to try all existing blocks when relation size <= N. Or equivalently,
hack the FSM code to return all N pages when it has no info.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2012-08-20 22:49:14 Outdated Japanse developers FAQ
Previous Message Phil Sorber 2012-08-20 22:31:57 Re: PATCH: psql boolean display