Dimitri Fontaine <[EMAIL PROTECTED]> 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! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers