From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andri Saar <andris(at)estpak(dot)ee> |
Cc: | Hannu Krosing <hannu(at)tm(dot)ee>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Serious issues with CPU usage |
Date: | 2003-09-08 14:04:33 |
Message-ID: | 9957.1063029873@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Andri Saar <andris(at)estpak(dot)ee> writes:
> If this is the best you can get with postgres right now, then I'll just have
> to increase the frequency of VACUUMing, but that feels like a hackish
> solution :(
Not at all. The overhead represented by VACUUM would have to be paid
somewhere, somehow, in any database. Postgres allows you to control
exactly when it gets paid.
It looks to me like throwing a plain VACUUM into your poller cycle
(or possibly VACUUM ANALYZE depending on how fast the table's stats
change) would solve your problems nicely.
Note that once you have that policy in place, you will want to do one
VACUUM FULL, and possibly a REINDEX, to get the table's physical size
back down to something commensurate with 2700 useful rows. I shudder
to think of where it had gotten to before. Routine VACUUMing should
hold it to a reasonable size after that.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Rhaoni Chiu Pereira | 2003-09-08 14:29:21 | Explain Doc |
Previous Message | Manfred Koizar | 2003-09-08 11:53:02 | Re: Serious issues with CPU usage |