Re: Avoiding vacuum full on an UPDATE-heavy table

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bill Montgomery <billm(at)lulu(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Avoiding vacuum full on an UPDATE-heavy table
Date: 2004-05-21 22:09:24
Message-ID: 16535.1085177364@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Bill Montgomery <billm(at)lulu(dot)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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Dan Harris 2004-05-21 23:23:36 tuning for AIX 5L with large memory
Previous Message Bill Montgomery 2004-05-21 21:29:33 Re: Avoiding vacuum full on an UPDATE-heavy table