Re: Avoiding vacuum full on an UPDATE-heavy table - Mailing list pgsql-performance

From Tom Lane
Subject Re: Avoiding vacuum full on an UPDATE-heavy table
Date
Msg-id 16535.1085177364@sss.pgh.pa.us
Whole thread Raw
In response to Avoiding vacuum full on an UPDATE-heavy table  (Bill Montgomery <billm@lulu.com>)
Responses index's relpages after table analyzed  (Litao Wu <litaowu@yahoo.com>)
List 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 by date:

Previous
From: Bill Montgomery
Date:
Subject: Re: Avoiding vacuum full on an UPDATE-heavy table
Next
From: Dan Harris
Date:
Subject: tuning for AIX 5L with large memory