Re: FSM rewrite committed, loose ends - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: FSM rewrite committed, loose ends
Date
Msg-id 87d4ildb8k.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: FSM rewrite committed, loose ends  (Dimitri Fontaine <dfontaine@hi-media.com>)
List pgsql-hackers
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!


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [BUG] pg_ctl restart at the vanilla v8.3.4
Next
From: Dimitri Fontaine
Date:
Subject: Re: FSM rewrite committed, loose ends