> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: 30 June 2005 14:41
> To: Dave Page
> Cc: Michael Glaesemann; PostgreSQL-patches; PostgreSQL-development
> Subject: Re: [PATCHES] Dbsize backend integration
>
> "Dave Page" <dpage@vale-housing.co.uk> writes:
> > Thanks Michael. We have 2 functions - 1 returns the on disk
> size of a
> > table or index without any additional parts such as indexes or toast
> > tables. The other function returns the total on disk size
> of a table and
> > all associated indexes and toast tables (and any indexes they might
> > have). The current names are pg_relation_size() for the
> first function,
> > and pg_table_size() for the second.
>
> That seems to me to work perfectly fine. "Relation" is being
> used here
> in its PG-jargon sense, that is an object described by one row of
> pg_class, and "table" is being used from the user's point of view.
I'm beginning to think that this is the best we'll get. Still, it is
documented, so it's not like the name has to be a perfect description of
the function's purpose.
> Or at least sort of --- I think most users know enough to distinguish
> tables and indexes. We can figure that the toast table and its index
> ought to be considered part of the "base" table, though, since the
> user doesn't have a choice about those.
>
> I've not been following the thread closely, so maybe this was already
> proposed and rejected, but what about:
>
> pg_relation_size: size of exactly the relation you point it at
> (table, index, toast table, whatever)
>
> pg_table_size: point it at heap, get size of
> heap+toast+toast_index
>
> pg_index_size: point it at heap, get size of all
> indexes for heap
> (excludes toast index)
>
> pg_total_size: point it at heap, get table_size + index_size
That moves the goal posts somewhat. We had settled on just the 2
functions - other combinations could easily be returned using
pg_relation_size and a little SQL for those people with more unusual
requirements. Unless you're particularly set on including these extra
two, I'm inclined to leave it as it is.
Regards, Dave.
