From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jeff Janes <jeff.janes@gmail.com>
cc: Mike Broers <mbroers@gmail.com>,
	"pgsql-admin@postgresql.org" <pgsql-admin@postgresql.org>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] after 9.2.4 patch vacuumdb -avz not analyzing all
 tables
In-reply-to: 
 <CAMkU=1zccxCVu051MHERJmGncvw1ckT2ndV34FvZ4Uy8_f7mAg@mail.gmail.com>
References: 
 <CAB9893het38CbHoHOt=GZ5tuUnb77EauGidjHsyy7Mqu_4_P9w@mail.gmail.com>
	<28473.1365724754@sss.pgh.pa.us>
	<CAMkU=1zccxCVu051MHERJmGncvw1ckT2ndV34FvZ4Uy8_f7mAg@mail.gmail.com>
Comments: In-reply-to Jeff Janes <jeff.janes@gmail.com>
	message dated "Thu, 11 Apr 2013 18:15:49 -0700"
Date: Thu, 11 Apr 2013 21:32:07 -0400
Message-ID: <534.1365730327@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-admin-owner@postgresql.org

Jeff Janes <jeff.janes@gmail.com> writes:
> I believe the rationale was so that an autovacuum would still look like it
> was needed, and get fired again the next naptime, so that it could continue
> with the truncation attempts.  (Rather than waiting for 20% turnover in the
> table before trying again).  I'm not convinced by this argument.  If the
> DBA is desperate to get the space back, they can go do vacuum full.

Well, that's why I think the lock abandonment shouldn't apply to manual
plain vacuum.  You shouldn't need to do a vacuum full for that; that'd
be a huge increase in the cost, not to mention that it'd transiently
require twice the disk space, hardly a good thing if you're short.

			regards, tom lane


-- 
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin