Re: fsm and vacuum

Hi,

Le 03/12/2010 00:19, Little, Douglas a écrit :
> [...]
> Thanks for the response.

No problem, but keep your anwser to the list, even if it's not the good
one :)

> Still a bit confused.
> Q: The guk settings  max_fsm_relations/pages are used by the db engine to set the size of the freespace map.

In memory, yes.

> Q: vacuum scans thru the file and adds free slots to the map when a table is vacuumed

Yes.

> Q: the map is used by the engine when inserting a row (new or versioned).

Yes.

> So is the only way to initialize the fsm to run vacuum?

Yes.

> We're experiencing problems using vacuum full.  GP recommends ctas/truncate/reload as alternative.
> Obviously won't work for system tables.
> My thought is vacuum full isn't working because the fsm was undersized.

vacuum full first scans the whole table to find free space, and then
scans backward to move every still-in-use space at the beginning of the
table. I don't know if vacuum full puts its information in the fsm, but
I believe so. So, if the fsm is undersized, you risk to have a not fully
effective vacuum full.

Anyway, you should probably not use vacuum full, unless you have a
*really* good reason.

Remember to REINDEX after your VACUUM FULL. Meaning you should probably
use CLUSTER, which will be fully effective and quicker. But you need an
index.

> Anything in the developers docs that would help me understand how it works?

This could be of interest:
 http://wiki.postgresql.org/wiki/VACUUM_FULL


-- 
Guillaumehttp://www.postgresql.frhttp://dalibo.com