Re: Avoiding vacuum full on an UPDATE-heavy table

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Avoiding vacuum full on an UPDATE-heavy table
Дата
Msg-id 16535.1085177364@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Avoiding vacuum full on an UPDATE-heavy table  (Bill Montgomery <billm@lulu.com>)
Ответы index's relpages after table analyzed  (Litao Wu <litaowu@yahoo.com>)
Список pgsql-performance
Bill Montgomery <billm@lulu.com> writes:
> I have a particularly troublesome table in my 7.3.4 database. It
> typically has less than 50k rows, and a usage pattern of about 1k
> INSERTs, 50-100k UPDATEs, and no DELETEs per day. It is vacuumed and
> analyzed three times per week.

You probably want to vacuum (non-FULL) once a day, if not more often.
Also take a look at your FSM settings --- it seems like a good bet that
they're not large enough to remember all the free space in your
database.

With adequate FSM the table should stabilize at a physical size
corresponding to number-of-live-rows + number-of-updates-between-VACUUMs,
which would be three times the minimum possible size if you vacuum once
a day (50K + 100K) or five times if you stick to every-other-day
(50K + 200K).  Your VACUUM FULL output shows that the table had bloated
to hundreds of times the minimum size:

> INFO:  Rel xxxx: Pages: 188903 --> 393; Tuple(s) moved: 17985.

and AFAIK the only way that will happen is if you fail to vacuum at all
or don't have enough FSM.

The indexes are looking darn large as well.  In 7.3 about the only thing
you can do about this is REINDEX the table every so often.  7.4 should
behave better though.

            regards, tom lane

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

Предыдущее
От: Bill Montgomery
Дата:
Сообщение: Re: Avoiding vacuum full on an UPDATE-heavy table
Следующее
От: Dan Harris
Дата:
Сообщение: tuning for AIX 5L with large memory