Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id E832164FCDD for ; Fri, 14 Nov 2008 05:45:04 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 55701-05 for ; Fri, 14 Nov 2008 05:45:01 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mail.postgresql.org (Postfix) with ESMTP id E188F64FC23 for ; Fri, 14 Nov 2008 05:45:00 -0400 (AST) Received: by ey-out-2122.google.com with SMTP id 6so522825eyi.61 for ; Fri, 14 Nov 2008 01:44:58 -0800 (PST) Received: by 10.210.22.16 with SMTP id 16mr828773ebv.132.1226655898786; Fri, 14 Nov 2008 01:44:58 -0800 (PST) Received: from oxford.xeocode.com.enterprisedb.com (LAubervilliers-153-52-14-234.w217-128.abo.wanadoo.fr [217.128.109.234]) by mx.google.com with ESMTPS id 23sm605058eya.7.2008.11.14.01.44.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 14 Nov 2008 01:44:55 -0800 (PST) To: Heikki Linnakangas Cc: PostgreSQL-development Subject: Re: Visibility map, partial vacuums In-Reply-To: <491D376B.9000608@enterprisedb.com> (Heikki Linnakangas's message of "Fri\, 14 Nov 2008 10\:31\:39 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) X-Draft-From: ("nnimap+imap.gmail.com:HACKERS" 48756) References: <4905AE17.7090305@enterprisedb.com> <491D376B.9000608@enterprisedb.com> From: Gregory Stark Organization: EnterpriseDB Date: Fri, 14 Nov 2008 09:44:52 +0000 Message-ID: <87r65eej57.fsf@oxford.xeocode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200811/985 X-Sequence-Number: 127697 Heikki Linnakangas writes: > The next question is whether the "pending rel deletion" stuff in smgr.c should > be moved to the new file too. It seems like it would belong there better. That > would leave smgr.c as a very thin wrapper around md.c Well it's just a switch, albeit with only one case, so I wouldn't expect it to be much more than a thin wrapper. If we had more storage systems it might be clearer what features were common to all of them and could be hoisted up from md.c. I'm not clear there are any though. Actually I wonder if an entirely in-memory storage system would help with the "temporary table" problem on systems where the kernel is too aggressive about flushing file buffers or metadata. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support!