In response to Vivek Khera <vivek@xxxxxxxxx>: > > On Nov 1, 2007, at 8:51 PM, Ow Mun Heng wrote: > > > Another question is, based on what I've read in the archives (in my > > laptop.. No-Inet conn @ work) Since I've overran my max_FSM, I'm > > basically screwed and will have to do a vacuum verbose FULL on the > > entire DB. Crap.. > > I've seen this repeated many times as well, and I can't think of a > really good reason why this should be true. It's not inherently true, it's just likely. > Once you increase max fsm > pages, won't the very next regular vacuum find all the free space in > pages and add them to the map anyway? Yes. > Ie, you've not "lost" any free > space once the next regular vacuum runs. At worst, you've got a > slightly bloated table because you allocated more pages rather than re- > using some, but is that worth a full vacuum? The situation you just described is the reason I recommend a full vacuum after such a situation has occurred. No, it's not required in all cases, but it's a lot easier to recommend than the research required to determine whether or not your table bloat is excessive enough to warrant it. If you can make the time to do the full vacuum, it's probably worth it, just for peace of mind. If it's difficult to schedule a full vacuum, then you need to carefully review various page usages to see if any individual tables are worth it and/or all kinds of careful consideration. As a result, I recommend a full vacuum, and if the person complains that they can't schedule it, _then_ I go into the details of how to figure out what else can/should be done. So I guess I'm recommending it to make my own life easier :) > I don't think it will be > unless you're *way* under the fsm pages needed and have been for a > long time. Frequently, when people ask for help because they've exceed max_fsm*, it's because they're not paying attention to their systems, and therefore the problem has been occurring for a while before it got so bad that they couldn't ignore it. As a result, a full vacuum is frequently a necessity. Folks who are monitoring their databases closely don't hit this problem nearly as often. -- Bill Moran http://www.potentialtech.com ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your message can get through to the mailing list cleanly
