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