Re: Eliminating VACUUM FULL WAS: remove flatfiles.c

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Eliminating VACUUM FULL WAS: remove flatfiles.c
Дата
Msg-id 24477.1252090122@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Eliminating VACUUM FULL WAS: remove flatfiles.c  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: Eliminating VACUUM FULL WAS: remove flatfiles.c  (Robert Haas <robertmhaas@gmail.com>)
Re: Eliminating VACUUM FULL WAS: remove flatfiles.c  (Boszormenyi Zoltan <zb@cybertec.at>)
Список pgsql-hackers
Josh Berkus <josh@agliodbs.com> writes:
>>> I have a client who uses temp tables heavily, hundreds of thousands of
>>> creates
>>> and drops per day. They also have long running queries. The only
>>> thing that
>>> keeps catalog bloat somewhat in check is vacuum full on bloated catalogs
>>> a few times a day. With

> Actually, this is a good point ... if we dropped VACUUM FULL, we'd need
> to also be able to call CLUSTER (or VACUUM REWRITE) on the system catalogs.

I don't think I believe the claim above that vacuum full is actually
necessary.  Reasonably aggressive regular vacuuming ought to do it.

We used to have a bug that caused row deletions during backend shutdown
to not get reported to the stats collector; which had the effect that
dead catalog entries for temp tables didn't get counted, and so autovac
didn't hit the catalogs often enough, and so you'd get bloat in exactly
this scenario.  I suspect the claim that manual vacuum full is necessary
is based on obsolete experience from before that bug got stomped.
It's hardly an ideal solution anyway given what an exclusive lock on
pg_class will do to the rest of the system --- and a cluster-like
cleanup won't be any better about that.
        regards, tom lane


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

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: Eliminating VACUUM FULL WAS: remove flatfiles.c
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Eliminating VACUUM FULL WAS: remove flatfiles.c