Skip site navigation (1) Skip section navigation (2)

Re: FSM rewrite committed, loose ends

From: "Dave Page" <dpage(at)pgadmin(dot)org>
To: "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: "Dimitri Fontaine" <dfontaine(at)hi-media(dot)com>, pgsql-hackers(at)postgresql(dot)org, "Gurjeet Singh" <singh(dot)gurjeet(at)gmail(dot)com>
Subject: Re: FSM rewrite committed, loose ends
Date: 2008-10-02 08:11:14
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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:

In response to

pgsql-hackers by date

Next:From: Dimitri FontaineDate: 2008-10-02 08:27:22
Subject: Re: FSM rewrite committed, loose ends
Previous:From: Heikki LinnakangasDate: 2008-10-02 08:07:14
Subject: Re: FSM rewrite committed, loose ends

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group