Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 9290064FD72 for ; Mon, 24 Nov 2008 11:23:40 -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 40407-06 for ; Mon, 24 Nov 2008 11:23:37 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mail.postgresql.org (Postfix) with ESMTP id F1F3464FCAC for ; Mon, 24 Nov 2008 11:23:36 -0400 (AST) Received: by ug-out-1314.google.com with SMTP id k40so761213ugc.7 for ; Mon, 24 Nov 2008 07:23:34 -0800 (PST) Received: by 10.66.243.12 with SMTP id q12mr1882224ugh.77.1227540214147; Mon, 24 Nov 2008 07:23:34 -0800 (PST) Received: from oxford.xeocode.com.enterprisedb.com ([87.127.95.198]) by mx.google.com with ESMTPS id j34sm2986928ugc.53.2008.11.24.07.23.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 24 Nov 2008 07:23:33 -0800 (PST) To: Tom Lane Cc: Heikki Linnakangas , PostgreSQL-development Subject: Re: Visibility map, partial vacuums In-Reply-To: <18086.1227537479@sss.pgh.pa.us> (Tom Lane's message of "Mon\, 24 Nov 2008 09\:37\:59 -0500") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) X-Draft-From: ("nnimap+imap.gmail.com:HACKERS" 49418) References: <4905AE17.7090305@enterprisedb.com> <491D376B.9000608@enterprisedb.com> <491D7F52.6070908@enterprisedb.com> <4925664C.3090605@enterprisedb.com> <26361.1227467112@sss.pgh.pa.us> <492A6032.6080000@enterprisedb.com> <18086.1227537479@sss.pgh.pa.us> From: Gregory Stark Organization: EnterpriseDB Date: Mon, 24 Nov 2008 15:23:31 +0000 Message-ID: <87ljv9rvv0.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/1579 X-Sequence-Number: 128291 Tom Lane writes: > Heikki Linnakangas writes: >> I've been thinking that we could add one frozenxid field to each >> visibility map page, for the oldest xid on the heap pages covered by the >> visibility map page. That would allow more fine-grained anti-wraparound >> vacuums as well. > > This doesn't strike me as a particularly good idea. Right now the map > is only hints as far as vacuum is concerned --- if you do the above then > the map becomes critical data. And I don't really think you'll buy > much. Hm, that depends on how critical the critical data is. It's critical that the frozenxid that autovacuum sees is no more recent than the actual frozenxid, but not critical that it be entirely up-to-date otherwise. So if it's possible for the frozenxid in the visibility map to go backwards then it's no good, since if that update is lost we might skip a necessary vacuum freeze. But if we guarantee that we never update the frozenxid in the visibility map forward ahead of recentglobalxmin then it can't ever go backwards. (Well, not in a way that matters) However I'm a bit puzzled how you could possibly maintain this frozenxid. As soon as you freeze an xid you'll have to visit all the other pages covered by that visibility map page to see what the new value should be. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support!