Re: FSM rewrite committed, loose ends

Dimitri Fontaine <dfontaine@hi-media.com> writes:

> 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)

What it does mean is that after a plain old VACUUM *all* the dead space in the
table will be noted and available for reuse. There isn't the risk that your
max_fsm_pages is too small and some of it gets forgotten.

The two headline numbers are percentage (and # bytes) of reusable free space
and percentage of non-reusable free space. The former being the thing to watch
to make sure you're vacuuming frequently enough and the latter being the thing
to watch to understand the impact of long-running transactions.

I don't think we really need to worry about the number of pages, or the
"usable" in the sense of "larger than the average allocation size"
measurements. They're both interesting but not as critical as the bottom-line
number which is how much of the table is being occupied by dead space.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication
support!