Re: vacuum full, why multiple times ?

Поиск
Список
Период
Сортировка
От Gaetano Mendola
Тема Re: vacuum full, why multiple times ?
Дата
Msg-id 422EDDA2.5000901@bigfoot.com
обсуждение исходный текст
Ответ на Re: vacuum full, why multiple times ?  (Michael Fuhr <mike@fuhr.org>)
Ответы Re: vacuum full, why multiple times ?  (Richard Huxton <dev@archonet.com>)
Список pgsql-performance
Michael Fuhr wrote:
> On Wed, Mar 09, 2005 at 02:02:13AM +0100, Gaetano Mendola wrote:
>
>
>>Basically I'm noticing that a simple vacuum full is not enough to
>>shrink completelly the table:
>>
>># vacuum full verbose url;
>>INFO:  vacuuming "public.url"
>>INFO:  "url": found 268392 removable, 21286 nonremovable row versions in 8563 pages
>>DETAIL:  22 dead row versions cannot be removed yet.
>
>
> How busy is the database?  I'd guess that each time you run VACUUM,
> there are still open transactions that have visibility to the dead
> rows, so VACUUM doesn't touch them.  Those transactions eventually
> complete, and eventually VACUUM FULL does what you're expecting.
> I don't know if that's the only possible cause, but I get results
> similar to yours if I have transactions open when I run VACUUM.
>

That was my first tough but it seem strange that 2 dead rows where
grabbing 7883 pages, don't you think ?


# vacuum full verbose url;
INFO:  vacuuming "public.url"
INFO:  "url": found 74 removable, 21266 nonremovable row versions in 8550 pages
DETAIL:  2 dead row versions cannot be removed yet.
[SNIP]
INFO:  "url": moved 11 row versions, truncated 8550 to 8504 pages


and in the next run:


# vacuum full verbose url;
INFO:  vacuuming "public.url"
INFO:  "url": found 13 removable, 21264 nonremovable row versions in 8504 pages
DETAIL:  0 dead row versions cannot be removed yet.
[SNIP]
INFO:  "url": moved 5666 row versions, truncated 8504 to 621 pages




Regards
Gaetano Mendola





В списке pgsql-performance по дате отправления:

Предыдущее
От: Gaetano Mendola
Дата:
Сообщение: Re: pl/pgsql faster than raw SQL?
Следующее
От: Hugo Ferreira
Дата:
Сообщение: Re: Help trying to tune query that executes 40x slower than in SqlServer