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 | 11360.1345502641@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
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Mon, Aug 20, 2012 at 4:27 PM, Tom Lane <tgl@sss.pgh.pa.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
В списке pgsql-hackers по дате отправления: