SEO

#1 (**permalink**) 04-11-2008, 04:33 AM

> -----Original Message-----
> From: Andrew Dunstan [mailto:andrew@dunslane.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.

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

#2 (**permalink**) 04-11-2008, 04:34 AM

Dave Page wrote:

> > -----Original Message-----
> > From: Andrew Dunstan [mailto:andrew@dunslane.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

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

#3 (**permalink**) 04-11-2008, 04:35 AM

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@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

#4 (**permalink**) 04-11-2008, 04:35 AM

Bruce Momjian <pgman@candle.pha.pa.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

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

SEO

Re: DBSize backend integration