Re: FSM rewrite committed, loose ends

Dimitri Fontaine wrote:
> Le mardi 30 septembre 2008, Heikki Linnakangas a écrit :
>>> You forgot the toast size.
>> Yeah, pg_total_relation_size() - pg_relation_size() is not equal to the
>> total size of indexes because of that.
> 
> Oops. Thanks for pointing this to me...
> 
>> But you can do SUM(pg_relation_size(index)) across all the indexes for
>> that:
> 
> For convenience, would it be possible to see about having all this provided by 
> PostgreSQL?
>  a. pg_relation_size()
>  b. pg_relation_toast_size()
>  c. pg_relation_fsm_size()
>  d. pg_relation_indexes_size()
>  e. pg_total_relation_size() = a + b + c + d
> 
> Are there some other things to add in the mix?

Should pg_relation_indexes_size() include the FSMs of the indexes? 
Should pg_relation_toast_size() include the toast index and FSM as well?

I fear we're going to end up with quite a lot of different combinations 
if we go down this path. I think we should just provide the building 
blocks, pg_relation_size() and pg_relation_fsm_size(), and the one total 
function pg_total_relation_size() that includes everything. If you're 
interested in the other combinations, you can call pg_relation_size() 
over all indexes, toast table etc. and sum them as you wish.

We'll also need to consider how the scheme scales when we add more 
relation forks. I'm still hoping to get the DSM into this release.

Perhaps we should provide an overloaded version of pg_relation_size() 
that takes the fork number (or name, for user-friendliness), instead of 
pg_relation_fsm_size(). So, you could use:

pg_relation_size('footable') for size of the main data fork
pg_relation_size('footable', 'fsm') for FSM size

> Maybe I'm the only one with the need for some simple functions covering all 
> the base, but I thought I'd ask nevertheless :)

What is your use case for all these, BTW?

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