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

Re: FSM rewrite committed, loose ends

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Dave Page <dpage(at)pgadmin(dot)org>
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 07:56:16
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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

In response to


pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2008-10-02 08:07:14
Subject: Re: FSM rewrite committed, loose ends
Previous:From: Florian WeimerDate: 2008-10-02 07:41:47
Subject: Re: Block-level CRC checks

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