From: | Mischa Sandberg <mischa(dot)sandberg(at)telus(dot)net> |
---|---|
To: | Bill Chandler <billybobc1210(at)yahoo(dot)com> |
Cc: | a3a18850(at)telus(dot)net, pgsql-perform <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Index bloat problem? |
Date: | 2005-04-21 22:15:22 |
Message-ID: | 1114121722.426825fa4474f@webmail.telus.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Quoting Bill Chandler <billybobc1210(at)yahoo(dot)com>:
> ... 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
From | Date | Subject | |
---|---|---|---|
Next Message | Bill Chandler | 2005-04-21 22:59:26 | Re: Index bloat problem? |
Previous Message | Stephan Szabo | 2005-04-21 21:15:08 | Re: index not used |