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

From Heikki Linnakangas
Subject FSM rewrite committed, loose ends
Date
Msg-id 48E2075B.8010104@enterprisedb.com
Whole thread Raw
Responses Re: FSM rewrite committed, loose ends  ("Gurjeet Singh" <singh.gurjeet@gmail.com>)
Re: FSM rewrite committed, loose ends  (Dimitri Fontaine <dfontaine@hi-media.com>)
Re: FSM rewrite committed, loose ends  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
List pgsql-hackers
I finally committed the new version of the FSM rewrite, after fixing the 
latest round of Tom's comments. There's a few loose ends I'm going to 
address as subsequent patches:

pg_relation_size() doesn't include the size of the FSM. Should it? I'm 
thinking "no", but pg_total_relation_size() should.

The FSM is not updated during WAL replay. That means that after crash 
recovery, the FSM won't be completely up-to-date, but at roughly the 
state it was at last checkpoint. In a warm stand-by, the FSM will 
reflect the situation at last full backup. We need to think when the FSM 
should be updated during WAL replay. Probably not after every record, 
because of the overhead, but certainly more often than never.

VACUUM VERBOSE output no longer prints the number of pages with "usable 
free space", because we no longer track such a value during the vacuum. 
You can use contrib/pg_freespacemap to view the contents of the FSM in 
detail, but should VACUUM VERBOSE still print something about the amount 
of free space on the relation? Perhaps the total amount of free space in 
the relation?

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: "Gurjeet Singh"
Date:
Subject: Re: Index size increases after VACUUM FULL
Next
From: Heikki Linnakangas
Date:
Subject: Re: Index size increases after VACUUM FULL