On Thu, 2003-11-13 at 13:10, scott.marlowe wrote:
So, if your table is HIGHLY updated, you may need to run a plain vacuum
very often, and that's where the autovacuum daemon comes in handy. Just
set it to run every 30 minutes or so, and let it go. It should only
vacuum the tables that have had lots of change, and leave the others
alone.
On Thu, 2003-11-13 at 19:37, Greg Stark wrote:
However on a big heavily used database where the fsm parameters haven't been
raised from the defaults it's possible that it isn't. And on a table where
large batch updates or deletes have been run it's possible to require a vacuum
full after the batch job creates lots of dead tuples.
Scott & Greg-
Thanks for this info. I'm sure this explains at least part of the problem. I can't remember the sequence of events from several months back, but I did once update ~20M rows of this 40M row this table, and I have also deleted certain sets of rows at various times. Suspecting that I had a swiss-cheese table, I reclustered on an index several times (which, I presume, is at least as good as vacuum (non-full) removing internal free space, with the benefit of optimized row ordering). Since I can't remember the order of operations, it's possible that I timed the slow query at nearly the worst state, and it's the kinda think I only wanted to endure once.
Thanks again,
Reece
--
Reece Hart, http://www.in-machina.com/~reece/, GPG:0x25EC91A0
|
