Quoting Bill Chandler <[EMAIL PROTECTED]>: > ... The normal activity is to delete 3-5% of the rows per day, > followed by a VACUUM ANALYZE. ... > However, on occasion, deleting 75% of rows is a > legitimate action for the client to take.
> > In case nobody else has asked: is your max_fsm_pages > > big enough to handle all the deleted pages, > > across ALL tables hit by the purge? > This parameter is most likely set incorrectly. So > that could be causing problems. Could that be a > culprit for the index bloat, though? Look at the last few lines of vacuum verbose output. It will say something like: free space map: 55 relations, 88416 pages stored; 89184 total pages needed Allocated FSM size: 1000 relations + 1000000 pages = 5920 kB shared memory. "1000000" here is [max_fsm_pages] from my postgresql.conf. If the "total pages needed" is bigger than the pages fsm is allocated for, then you are bleeding. -- "Dreams come true, not free." -- S.Sondheim, ITW ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq