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