Matthew T. O'Connor wrote:

Is there any way to avoid doing a periodic VACUUM FULL on this table,
given the fairly radical usage pattern? Or is the (ugly) answer to
redesign our application to avoid this usage pattern?


pg_autovacuum would probably help as it monitors activity and vacuumus
tables accordingly. It is not included with 7.3.x but if you download it
and compile yourself it will work against a 7.3.x server.


As a quick fix, since we're upgrading to 7.4.2 in a few weeks anyhow (which includes pg_autovacuum), I've simply set up an hourly vacuum on this table. It only takes ~4 seconds to execute when kept up on an hourly basis. Is there any penalty to vacuuming too frequently, other than the time wasted in an unnecessary vacuum operation?

My hourly VACUUM VERBOSE output now looks like this:

INFO: --Relation public.xxxx--
INFO: Index xxxx_yyyy_idx: Pages 30452; Tuples 34990: Deleted 1226.
CPU 0.67s/0.18u sec elapsed 0.87 sec.
INFO: Index xxxx_yyyy_idx: Pages 19054; Tuples 34991: Deleted 1226.
CPU 0.51s/0.13u sec elapsed 1.35 sec.
INFO: Removed 1226 tuples in 137 pages.
CPU 0.01s/0.00u sec elapsed 1.30 sec.
INFO: Pages 13709: Changed 31, Empty 0; Tup 34990: Vac 1226, Keep 0, UnUsed 567233.
Total CPU 1.58s/0.31u sec elapsed 3.91 sec.
INFO: Analyzing public.xxxx
VACUUM


With regards to Vivek's post about index bloat, I tried REINDEXing before I did a VACUUM FULL a month ago when performance had gotten dismal. It didn't help :-(

Best Regards,

Bill Montgomery

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Reply via email to