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
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? |