Re: FSM rewrite committed, loose ends

Dave Page wrote:
> On Tue, Sep 30, 2008 at 2:53 PM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com> wrote:
>> Should pg_relation_indexes_size() include the FSMs of the indexes? Should
>> pg_relation_toast_size() include the toast index and FSM as well?
> 
> It might be worth revisiting the near identical discussions we had
> when Andreas & I integrated this stuff into the backend for 8.1.

Good point. The previous discussions evolved to having two functions, 
pg_relation_size() and pg_total_relation_size(), where 
pg_relation_size() is as fine-grained as possible, allowing you to get 
the size of each heap, index, toast table and toast index individually, 
and pg_total_relation_size() is a convenience function to sum them all. 
Following that philosophy, I think the idea of adding a new optional 
"fork name" argument to pg_relation_size() is the right thing to do:

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

There's currently two variants of both pg_relation_size and 
pg_total_relation_size, one takes an OID and one takes a relation name 
as argument. Any objections to having just one of each function, taking 
a 'regclass'? The user-visible behavior wouldn't change, but I thought 
I'd ask first in case I'm missing something.

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