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 по дате отправления:

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: Manual vacs 5x faster than autovacs?
Следующее
От: Lists
Дата:
Сообщение: Re: SSD + RAID