Re: Manual vacs 5x faster than autovacs?
От | Scott Marlowe |
---|---|
Тема | Re: Manual vacs 5x faster than autovacs? |
Дата | |
Msg-id | dcc563d10911132202o79ec3abaw4d86d172f4fbe2b2@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Manual vacs 5x faster than autovacs? (Craig Ringer <craig@postnewspapers.com.au>) |
Список | pgsql-performance |
On Fri, Nov 13, 2009 at 9:45 PM, Craig Ringer <craig@postnewspapers.com.au> wrote: > On 14/11/2009 11:55 AM, Scott Marlowe wrote: >> On Fri, Nov 13, 2009 at 8:31 PM, Craig Ringer >> <craig@postnewspapers.com.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. Yeah, it should be a name that when you're typing it you know you screwed up to get where you are. The opleasemayihavebackthespaceilostwhilelockingmytablesandbloatingmyindexes command. No chance you'll run it by mistake either!
В списке pgsql-performance по дате отправления: