Re: FSM rewrite committed, loose ends

Hi,

Le mardi 30 septembre 2008, Heikki Linnakangas a écrit :
> pg_relation_size() doesn't include the size of the FSM. Should it? I'm
> thinking "no", but pg_total_relation_size() should.

What's practical about pg_relation_size() and pg_total_relation_size() as of
8.3 is that the diff is the cumulated indexes storage volume. Your proposal
makes it harder to get this information, but sounds good otherwise.
Would it be possible to add in some new APIs to?
a. pg_relation_size()
b. pg_relation_fsm_size()
c. pg_relation_indexes_size()
d. pg_total_relation_size() = a + b + c

This scheme will need new functions for each new kind of forks, but I think
it's a good idea for the user to be able to know which fork is responsible
for what on-disk volume.

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

What about another function to get just this information?
e. pg_relation_free_space()

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)

Regards, keep up the good (team) work :)
--
dim