Re: FSM rewrite committed, loose ends

On Thu, Oct 2, 2008 at 8:56 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:

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

Sounds reasonable.

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

None here.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com