Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id A67DF914534 for ; Thu, 1 Dec 2011 03:16:23 -0400 (AST) Received: from exprod7og113.obsmtp.com ([64.18.2.179]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1RW0sW-0002ge-2f for pgsql-hackers@postgresql.org; Thu, 01 Dec 2011 07:16:23 +0000 Received: from mail-bw0-f45.google.com ([209.85.214.45]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTtcptbUBcidOMKR0lelIUJO+UUk9susK@postini.com; Wed, 30 Nov 2011 23:16:19 PST Received: by bkar19 with SMTP id r19so2271472bka.32 for ; Wed, 30 Nov 2011 23:16:04 -0800 (PST) Received: by 10.204.148.67 with SMTP id o3mr6013453bkv.130.1322723764347; Wed, 30 Nov 2011 23:16:04 -0800 (PST) Received: from [192.168.1.100] (dsl-hkibrasgw2-ff6cc300-200.dhcp.inet.fi. [88.195.108.200]) by mx.google.com with ESMTPS id fa8sm9349164bkc.14.2011.11.30.23.16.01 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Nov 2011 23:16:02 -0800 (PST) Message-ID: <4ED729B0.2000308@enterprisedb.com> Date: Thu, 01 Dec 2011 09:16:00 +0200 From: Heikki Linnakangas User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; fi-FI; rv:1.9.2.23) Gecko/20111010 Icedove/3.1.15 MIME-Version: 1.0 To: Tom Lane CC: Robert Haas , Florian Weimer , pgsql-hackers@postgresql.org Subject: Re: Large number of open(2) calls with bulk INSERT into empty table References: <82ipm51tcd.fsf@mid.bfk.de> <23238.1322674187@sss.pgh.pa.us> <25165.1322678715@sss.pgh.pa.us> In-Reply-To: <25165.1322678715@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -4.2 (----) X-Archive-Number: 201112/2 X-Sequence-Number: 199254 On 30.11.2011 20:45, Tom Lane wrote: > Robert Haas 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