Skip site navigation (1) Skip section navigation (2)

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

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, 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: 2011-12-01 07:16:00
Message-ID: 4ED729B0.2000308@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On 30.11.2011 20:45, Tom Lane wrote:
> Robert Haas<robertmhaas(at)gmail(dot)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

In response to

pgsql-hackers by date

Next:From: Magnus HaganderDate: 2011-12-01 07:50:14
Subject: Re: Review of VS 2010 support patches
Previous:From: YAMAMOTO TakashiDate: 2011-12-01 06:29:32
Subject: Re: synchronous commit vs. hint bits

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group