Re: FSM rewrite committed, loose ends

Dimitri Fontaine wrote:
> Le mardi 30 septembre 2008, Heikki Linnakangas a écrit :
>> Dimitri Fontaine wrote:
>>> Question for the slow readers: this new FSM scheme being dynamic, it's no
>>> longer possible to have table bloat, right?
>>> (where table bloat is full of dead-for-any-transaction tuples, and you
>>> have to CLUSTER or VACUUM FULL to be able to reuse the space it takes)
>> No, it didn't change that. Regular VACUUMing or autovacuum is still needed.
> 
> But IIUC correctly it's no longer possible for PostgreSQL to forget about 
> where bloat is, so regular vacuuming will know how clean out any bloat any 
> time?

That has never been a problem. VACUUM has always found and removed all 
dead tuples.

> For example, a purge script which does a large DELETE could overrun the 
> max_fsm_pages setting, resulting in permanent bloat (until table rewrite). 
> This large DELETE will now be tracked completely by the new FSM, so 
> autovacuum will be able to have the space reused later?

It isn't really permanent. If you increase max_fsm_pages, restart and 
vacuum again, vacuum will pick up all the empty pages.

But yes, the new FSM is always large enough to hold information about 
all pages in the relation, so you can no longer get table bloat because 
of a too small max_fsm_pages or max_fsm_relations setting.

You can still get table bloat because of other reasons, like not 
vacuuming often enough.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com