|
>> Am I wrong? > > Probably. My first concern is to make sure you aren't doing VACUUM > FULL as part of your maintenance cycle. That option is meant for > recovery from extreme bloat, and is sort of a "last resort". Good - glad to be wrong about that! We do mostly inserts, no updates and very few deletes. We drop entire tables but don't delete often. We have very long rows, though. Do you think the above is a situation likely to create extreme bloat? My Sybase experience with extreme bloat was that it was caused by a three-field clustered index in a very long short-row table over time (~a year). This job doesn't use clustered indexes. I thought we had to do vacuum full to avoid transaction ID wraparound/reset issues? We do have a lot of transactions, a whole lot. Are you saying that most admins avoid VACUUM FULL as much as possible? What about XID? Thanks, Jennifer Other > vacuums coexist with normal usage as long as you have things properly > configured for your environment. You probably won't have a need to > reindex if you stay away from VACUUM FULL and otherwise avoid unusual > activity which causes index bloat; however, if you do need to reindex > without down time, there is CREATE INDEX CONCURRENTLY which can be > used to achieve that. > > -Kevin Windows Live™: Keep your life in sync. Check it out. |
