Received: from localhost (unknown [200.46.204.184])
	by developer.postgresql.org (Postfix) with ESMTP id 763CC2E0031
	for <pgsql-performance-postgresql.org@developer.postgresql.org>;
	Fri,  2 May 2008 19:29:17 -0300 (ADT)
Received: from developer.postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024)
	with ESMTP id 46708-03
	for <pgsql-performance-postgresql.org@developer.postgresql.org>;
	Fri,  2 May 2008 19:29:08 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from gwmta.wicourts.gov (gwmta.wicourts.gov [165.219.244.99])
	by developer.postgresql.org (Postfix) with ESMTP id 7B63F2E003B
	for <pgsql-performance@postgresql.org>;
	Fri,  2 May 2008 19:29:14 -0300 (ADT)
Received: from Courts-MTA by gwmta.wicourts.gov
	with Novell_GroupWise; Fri, 02 May 2008 17:29:13 -0500
Message-Id: <481B4F3E.EE98.0025.0@wicourts.gov>
X-Mailer: Novell GroupWise Internet Agent 7.0.3 
Date: Fri, 02 May 2008 17:29:00 -0500
From: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
To: "Alexy Khrabrov" <deliverable@gmail.com>
Cc: "Greg Smith" <gsmith@gregsmith.com>,
	<pgsql-performance@postgresql.org>
Subject: Re: two memory-consuming postgres processes
References: <A728C858-76CF-473F-917B-3C9EA4AA75CF@gmail.com>
	<dcc563d10805021230i5916561k3962a41e2afa894c@mail.gmail.com>
	<27A4D379-2553-496D-A96C-102F2A5E62C2@gmail.com>
	<dcc563d10805021253n1589baa7u559fdfc8053d23d3@mail.gmail.com>
	<21403.1209759217@sss.pgh.pa.us>
	<72E02D29-848B-467A-AE6B-401568010254@gmail.com>
	<dcc563d10805021340u274ff4fegcf8902f66118d7c1@mail.gmail.com>
	<481B8160.2090106@emolecules.com>
	<C25E5DBA-B649-4483-B1A2-2A881522B891@gmail.com>
	<Pine.GSO.4.64.0805021714580.2455@westnet.com>
	<1F7A4C3D-C8A3-44BC-A324-E9BA409BB479@gmail.com>
	<481B44AF.EE98.0025.0@wicourts.gov>
	<C123A0EA-7B13-4297-9263-270224DF1F10@gmail.com>
In-Reply-To: <C123A0EA-7B13-4297-9263-270224DF1F10@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200805/38
X-Sequence-Number: 30006

>>> Alexy Khrabrov wrote: 
 
> OK.  I've cancelled all previous attempts at UPDATE and will now  
> create some derived tables.  See no changes in the previous huge
table  
> -- the added column was completely empty.  Dropped it.  Should I  
> vacuum just in case, or am I guaranteed not to have any extra rows  
> since no UPDATE actually went through and none are showing?
 
The canceled attempts would have left dead space.  If you have
autovacuum running, it probably made the space available for reuse,
but depending on exactly how you got to where you are, you may have
bloat.  Personally, I would do a VACUUM ANALYZE VERBOSE and capture
the output.  If bloat is too bad, you may want to CLUSTER the table
(if you have the free disk space for a temporary extra copy of the
table) or VACUUM FULL followed by REINDEX (if you don't have that much
free disk space).
 
Let us know if you need help interpreting the VERBOSE output.
 
-Kevin