Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 97AC564FDA4 for ; Tue, 28 Oct 2008 11:23:45 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 69448-03 for ; Tue, 28 Oct 2008 11:23:36 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail136176.authsmtp.com (outmail136176.authsmtp.com [62.13.136.176]) by postgresql.org (Postfix) with ESMTP id 3E9EE650040 for ; Tue, 28 Oct 2008 11:23:08 -0300 (ADT) Received: from mail-c189.authsmtp.com (mail-c189.authsmtp.com [62.13.128.71]) by punt6.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id m9SEMRbG062293; Tue, 28 Oct 2008 14:22:27 GMT Received: from [192.168.0.3] (85-211-99-122.dyn.gotadsl.co.uk [85.211.99.122]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id m9SEMMdS002950; Tue, 28 Oct 2008 14:22:24 GMT Subject: Re: Visibility map, partial vacuums From: Simon Riggs To: Heikki Linnakangas Cc: PostgreSQL-development In-Reply-To: <49070C29.9090508@enterprisedb.com> References: <4905AE17.7090305@enterprisedb.com> <1225193108.3971.154.camel@ebony.2ndQuadrant> <49070C29.9090508@enterprisedb.com> Content-Type: text/plain Date: Tue, 28 Oct 2008 14:22:15 +0000 Message-Id: <1225203735.3971.167.camel@ebony.2ndQuadrant> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 Content-Transfer-Encoding: 7bit X-Server-Quench: d7e43092-a4fb-11dd-bc7a-001f29070be2 X-AuthRoute: OCdxZQATClZOTQEd DAteCiNZVAwpPBRK HVkIKg5MJUcNSQVJ NksadBtFag1bYlpF HGQLW1xEUVl7W2F/ aQ8fZQBDYEtPQQxj TklLQE1QEQdtHhxP Wxd9J2QPI2ZGeHx5 YEYsXHJfWAouchN5 QU5dF3BXYTEydWEe BBRFJVBTIR5Kfh4T aFl/U3NfNGdJBC9q VzwTFhsSEA9kHWxr QxoMJ1MWQFoaVjs1 X1RKBTw1AUwMQ20t Jhc7N1sHdDg2 X-Authentic-SMTP: 61633235383639.kestrel.dmpriest.net.uk:1378/Kp X-Report-SPAM: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-Virus-Status: No virus detected - but ensure you scan with your own anti-virus system! 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: 200810/1407 X-Sequence-Number: 126424 On Tue, 2008-10-28 at 14:57 +0200, Heikki Linnakangas wrote: > Simon Riggs wrote: > > On Mon, 2008-10-27 at 14:03 +0200, Heikki Linnakangas wrote: > >> One option would be to just ignore that problem for now, and not > >> WAL-log. > > > > Probably worth skipping for now, since it will cause patch conflicts if > > you do. Are there any other interactions with Hot Standby? > > > > But it seems like we can sneak in an extra flag on a HEAP2_CLEAN record > > to say "page is now all visible", without too much work. > > Hmm. Even if a tuple is visible to everyone on the master, it's not > necessarily yet visible to all the read-only transactions in the slave. Never a problem. No query can ever see the rows removed by a cleanup record, enforced by the recovery system. > > Does the PD_ALL_VISIBLE flag need to be set at the same time as updating > > the VM? Surely heapgetpage() could do a ConditionalLockBuffer exclusive > > to set the block flag (unlogged), but just not update VM. Separating the > > two concepts should allow the visibility check speed gain to more > > generally available. > > Yes, that should be possible in theory. There's no version of > ConditionalLockBuffer() for conditionally upgrading a shared lock to > exclusive, but it should be possible in theory. I'm not sure if it would > be safe to set the PD_ALL_VISIBLE_FLAG while holding just a shared lock, > though. If it is, then we could do just that. To be honest, I'm more excited about your perf results for that than I am about speeding up some VACUUMs. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support