From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Treat <rtreat(at)webmd(dot)net> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: table size growing out of control |
Date: | 2002-07-16 05:38:46 |
Message-ID: | 3459.1026797926@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Robert Treat <rtreat(at)webmd(dot)net> writes:
> For the record, we went through this procedure about 2 weeks ago (slow
> queries, reindex, vacuum, drop/reload) So I am wondering what might be
> causing the table to grow so large. We run a function against the table
> about every 5 minutes which updates on average maybe 100 rows and adds
> rows at the rate of maybe 1 an hour, but otherwise everything else is
> selects. I wouldn't think that continual updates would have such a
> adverse effect on table size, and even if so shouldn't vacuum take care
> of this?
You can do VACUUM FULL if you want to re-shrink the table. If you want
to stick with plain VACUUMs then you need to do them often enough to
keep the table size reasonable. You didn't say what your maintenance
schedule is...
If your overall database is large then you might need to increase the
size of the free space map (see postgresql.conf).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-07-16 05:47:46 | Re: Question: merit / feasibility of compressing frontend |
Previous Message | Tracy Gong | 2002-07-16 03:58:59 | Help for "/cygipc-1.11-1.bz2: can not open: no such file or directory." |