Re: Manual vacs 5x faster than autovacs?

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
Cc: Dave Crooke <dcrooke(at)gmail(dot)com>, Wayne Beaver <wayne(at)acedsl(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Manual vacs 5x faster than autovacs?
Date: 2009-11-14 04:45:19
Message-ID: 4AFE35DF.5010307@postnewspapers.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On 14/11/2009 11:55 AM, Scott Marlowe wrote:
> On Fri, Nov 13, 2009 at 8:31 PM, Craig Ringer
> <craig(at)postnewspapers(dot)com(dot)au> wrote:
>> On 13/11/2009 2:29 PM, Dave Crooke wrote:
>>
>>> Beware that VACUUM FULL locks an entire table at a time :-)
>>
>> ... and often bloats its indexes horribly. Use CLUSTER instead if you
>> need to chop a table that's massively bloated down to size; it'll be
>> much faster, and shouldn't leave the indexes in a mess.
>>
>> I increasingly wonder what the purpose of VACUUM FULL in its current
>> form is.
>
> There's been talk of removing it. It's almost historical in nature
> now, but there are apparently one or two situations, like when you're
> almost out of space, that vacuum full can handle that dumping reload
> or cluster or whatnot can't do without more extra space.

Perhaps it should drop and re-create indexes as well, then? (Or disable
them so they become inconsistent, then REINDEX them - same deal). It'd
run a LOT faster, and the index bloat issue would be gone.

The current form of the command just invites misuse and misapplication.

--
Craig Ringer

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Scott Marlowe 2009-11-14 06:02:17 Re: Manual vacs 5x faster than autovacs?
Previous Message Scott Marlowe 2009-11-14 03:55:12 Re: Manual vacs 5x faster than autovacs?