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
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 |