Re: FSM rewrite committed, loose ends

Dave Page wrote:
> On Tue, Sep 30, 2008 at 2:53 PM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)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