Re: FSM rewrite committed, loose ends

On Tue, Sep 30, 2008 at 4:32 PM, Heikki Linnakangas <
heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:

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

No

> but pg_total_relation_size() should.

+1

> 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.

I haven't seen the code, but would it be possible to have a resource manager
for FSM, and let that rmgr accumulate the FSM updates in memory and then
flush the changes after a threshold (or at Checkpoint record, whichever is
first).

>
> 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?

I vote for contrib/pg_freespacemap functions to be included in the core
since FSM is in core. If that happens, we wouldn't need VACUUM for reporting
this.

Best regards,
--
gurjeet[(dot)singh](at)EnterpriseDB(dot)com
singh(dot)gurjeet(at){ gmail | hotmail | indiatimes | yahoo }.com

EnterpriseDB http://www.enterprisedb.com

Mail sent from my BlackLaptop device