Re: DBSize backend integration

> -----Original Message-----
> From: Andrew Dunstan [mailto:andrew(at)dunslane(dot)net]
> Sent: 24 June 2005 21:12
> To: Bruce Momjian
> Cc: Dave Page; PostgreSQL-development
> Subject: Re: [HACKERS] DBSize backend integration
>
>
>
> Bruce Momjian wrote:
>
> >
> >So drop total_relation_size(), relation_size_components(), and what
> >else?
>
> But these answer easily the question I see most asked - how
> much space
> in total does the relation occupy. I'd like to see at least one of
> these, properly named and fixed w.r.t. schemas. Getting
> total_relation_size() from relation_size_components() would
> be easy, so
> if we only keep one then keep relation_size_components().

relation_size_components() depends on total_relation_size() (which I
have to agree could be useful). I think relation_size_components() is
unecessary though - it looks like it was designed to show a summary
rather than as a view to be used by other clients (if that makes
sense!).

Regards, Dave.

Dave Page wrote:

> > -----Original Message-----
> > From: Andrew Dunstan [mailto:andrew(at)dunslane(dot)net]
> > Sent: 24 June 2005 21:12
> > To: Bruce Momjian
> > Cc: Dave Page; PostgreSQL-development
> > Subject: Re: [HACKERS] DBSize backend integration
> >
> > Bruce Momjian wrote:
> >
> > >
> > >So drop total_relation_size(), relation_size_components(), and what
> > >else?
> >
> > But these answer easily the question I see most asked - how
> > much space
> > in total does the relation occupy. I'd like to see at least one of
> > these, properly named and fixed w.r.t. schemas. Getting
> > total_relation_size() from relation_size_components() would
> > be easy, so
> > if we only keep one then keep relation_size_components().
>
> relation_size_components() depends on total_relation_size() (which I
> have to agree could be useful). I think relation_size_components() is
> unecessary though - it looks like it was designed to show a summary
> rather than as a view to be used by other clients (if that makes
> sense!).

I agree that total_relation_size() is quite useful at least when used from
the command line. It should give you the correct answer to what space a
table including indexes and _toast_tables_ occupies.

I am not sure about relation_size_components.

Best Regards,
Michael Paesold

Michael Paesold wrote:
> > relation_size_components() depends on total_relation_size() (which I
> > have to agree could be useful). I think relation_size_components() is
> > unecessary though - it looks like it was designed to show a summary
> > rather than as a view to be used by other clients (if that makes
> > sense!).
>
> I agree that total_relation_size() is quite useful at least when used from
> the command line. It should give you the correct answer to what space a
> table including indexes and _toast_tables_ occupies.

Can someone come up with a better name than total_relation_size(),
because we already have relation_size()? The problem is that in the
first case, relation means the relation/indexes/toast, and in the second
it is just the heap. Should we call relation_size() pg_heap_size(). I
prefer that.

I think we are considering adding pg_* too. Anyway, this is the time to
add consistency.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Can someone come up with a better name than total_relation_size(),
> because we already have relation_size()? The problem is that in the
> first case, relation means the relation/indexes/toast, and in the second
> it is just the heap. Should we call relation_size() pg_heap_size(). I
> prefer that.

Both "relation" and "heap" are PG-isms I think. Seems to me we should
be using "pg_table_size" for the "most natural" unit, which is either
heap+toast+toast_index or heap+toast+toast_index+table_indexes depending
on whether you agree with the SQL committee that indexes are an
implementation detail ...

regards, tom lane