On 7/3/05, Andreas Pflug <[EMAIL PROTECTED]> wrote:
> > Yup, attached. Per our earlier conversation, pg_dbfile_size() now
> > returns the size of a table or index, and pg_relation_size() returns the
> > total size of a relation and all associated indexes and toast tables
> > etc.
>
> pg_relation_size's name is quite unfortunate, since the 8.0 contrib
> function does something different. And pg_dbfile_size sounds misleading,
> suggesting it takes a filename or relfilenode as parameter.
Oh, I think pg_dbfile_size is best so far. Assuming someone gives it a
filename, she'll get an error message. So practically it cannot be used
wrong by mistake. It is not so with other names proposed for that
function. Their names suggest they'll happily accept table/index/whatever
and return some size... But what size, that is the question. At least
pg_dbfile_size states that clearly. :)
As for pg_relation_size. I think its good enough, or at least I don't know
any better. I think it is better than pg_table_size, since people tend to
have personalized ideas what a table size is (a table with TOAST and
TOAST's indexes; a table with PRIMARY KEY,UNIQUE constraint indexes,
a table with all indexes involved,. etc/). pg_relation_size seems. at least
to me, to imply that its greedy and will take not only the table, and also
things the table is closely related to, like all the indexes.
The fun will begin when we'll have full working table partitioning and
multitable
indexes. ;))))
Regards,
Dawid
---------------------------(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
