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 -- Guillaume http://www.postgresql.fr http://dalibo.com -- Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-support
