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

On 30.11.2011 20:45, Tom Lane wrote:
> Robert Haas<robertmhaas@gmail.com>  writes:
>> Yikes!  A table with 4 bytes of useful data is consuming 40kB on disk
>> - 8kB in the main form, 8kB in the VM fork, and 24kB in the FSM fork.
>> Ouch!
>
> Yeah, ouch.  Why is the FSM fork eating so much space --- I'd have
> expected 8k there, but 24?

The FSM is a three-level tree (with the default BLCKSZ), and the code 
creates all three levels right from the start. That keeps the addressing 
simple, you can easily calculate the location of the FSM entry for a 
given page. I tried to come up with an addressing scheme that would 
allow adding upper-level pages only as needed, but failed. If you have 
any ideas on that, I'm all ears. I have a feeling that there's got to be 
some well-known scheme that does that, but I didn't find it. The current 
addressing scheme is documented in storage/freespace/README, in section 
Higher-Level Structure.

> Also, if VACUUM is going to cause the FSM to be created anyway, there
> may not be a lot of point to refraining from creating the first page
> right away.

Perhaps we should refrain from creating a FSM unless the table is larger 
than 1 block.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com