Received: from localhost (unknown [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id 6233D9F9CE4 for ; Sat, 29 Sep 2007 05:06:20 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024) with ESMTP id 89032-07 for ; Sat, 29 Sep 2007 05:06:11 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.5 Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by postgresql.org (Postfix) with ESMTP id A14459F9BF2 for ; Sat, 29 Sep 2007 05:06:13 -0300 (ADT) Received: by ug-out-1314.google.com with SMTP id j3so1696884ugf for ; Sat, 29 Sep 2007 01:06:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; bh=mlFuGL6MnaUljvaMtxbzxN8Fw1anOyhzPX03BkIE7S0=; b=mpHpuyUBBnrg0a/U6ZZL7lGw+e2DzkX9AYqbyF/lRp20JRpBXxnilJpmxTAie7tT7Ta6FsUCHr11XMpYQM1q2YAhHogwc1GtI2D0iyBWasnpHe20FQ8/gQVlYdERlxGyKwWfq+oxZ1lBn8rAZ/Ew2Oo6LocnVdboa620USvrwjc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=PrCWvuAM6PWI3s2Rk3BaV/FycvFw3sk1BerYnzZWuWkc8a9OAUjJ5n5xbE2Gb7qRXTm8IysJINHTQpYsO5GEJw4PHtARB9V1SVKBgPi34J9WMQXNMYBo26y86SqLdn6LDcqjsaq9qG/gfq540HUsMIXRrScDph2YLSc8UJXUyd4= Received: by 10.67.24.18 with SMTP id b18mr6121304ugj.1191053171994; Sat, 29 Sep 2007 01:06:11 -0700 (PDT) Received: from ?192.168.1.34? ( [86.27.80.139]) by mx.google.com with ESMTPS id i39sm9664455ugd.2007.09.29.01.06.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 29 Sep 2007 01:06:10 -0700 (PDT) Message-ID: <46FE073E.4040003@enterprisedb.com> Date: Sat, 29 Sep 2007 09:05:18 +0100 From: Heikki Linnakangas User-Agent: Icedove 1.5.0.12 (X11/20070730) MIME-Version: 1.0 To: Ron Mayer CC: pgsql-performance@postgresql.org Subject: Re: Non-blocking vacuum full References: <20070928180649.GA6579@hyperion.scode.org> <46FD5695.6000302@enterprisedb.com> <46FDBC84.2000205@cheapcomplexdevices.com> In-Reply-To: <46FDBC84.2000205@cheapcomplexdevices.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200709/477 X-Sequence-Number: 27022 Ron Mayer wrote: > Heikki Linnakangas wrote: >> Peter Schuller wrote: >>> to have a slow background process (similar to normal non-full vacuums >> ... >> I think it's doable, if you take a copy of the tuple, and set the ctid >> pointer on the old one like an UPDATE, and wait until the old tuple is >> no longer visible to anyone before removing it. It does require some >> changes to tuple visibility code. > > Wouldn't just having this slow background process > repeatedly alternating between > update table set anycol=anycol where ctid > [some ctid near the end] > and running normal VACUUM statements do what the original poster > was asking? Almost. Updaters would block waiting for the UPDATE, and updaters in serializable mode would throw serialization errors. And the "WHERE ctid > ?" would actually result in a seq scan scanning the whole table, since our tid scans don't support inequality searches. > And with 8.3, I guess also avoiding HOT? HOT shouldn't cause any complications here AFAICS. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com