Thread: Re: [PATCHES] Dbsize backend integration
> -----Original Message----- > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > Sent: 02 July 2005 21:30 > To: Bruce Momjian > Cc: Dave Page; PostgreSQL-patches; PostgreSQL-development > Subject: Re: [PATCHES] Dbsize backend integration > > > Is a new version of this patch coming? 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. Regards, Dave.
Attachment
Dave Page wrote: > > > >>-----Original Message----- >>From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] >>Sent: 02 July 2005 21:30 >>To: Bruce Momjian >>Cc: Dave Page; PostgreSQL-patches; PostgreSQL-development >>Subject: Re: [PATCHES] Dbsize backend integration >> >> >>Is a new version of this patch coming? > > > 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. Regards, Andreas
Andreas Pflug wrote: > Dave Page wrote: > > > > > > > >>-----Original Message----- > >>From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > >>Sent: 02 July 2005 21:30 > >>To: Bruce Momjian > >>Cc: Dave Page; PostgreSQL-patches; PostgreSQL-development > >>Subject: Re: [PATCHES] Dbsize backend integration > >> > >> > >>Is a new version of this patch coming? > > > > > > 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. Hmm. I don't see how we can call it pg_table_size because people think of tables and indexes, while relation has a more inclusive suggestion. As far as pg_dbfile_size, do you have any other idea for a name? To me, it returns the size of the 'db file' associated with the heap/index/toast. -- 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
On Jul 3, 2005, at 8:35 AM, Bruce Momjian wrote: > Andreas Pflug wrote: > >> Dave Page 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. >> > > Hmm. I don't see how we can call it pg_table_size because people > think > of tables and indexes, while relation has a more inclusive suggestion. I'm not familiar enough with the backend code to know if there's a semantic difference between how relation and table are treated, so my line of reasoning may be flawed. However, I try to use the term relation when I'm discussing things at a logical level--the predicates the data represents. Indexes and toast tables are implementation details, separate from the predicates the relation represents. The distinction between table and relation is very small, and using both pg_table_size and pg_relation_size but with different meanings is going to have people dependent on the documentation to remember the difference; pg_table_size and pg_relation_size both have the same meaning to me: the size of the table or index. I'd lean towards pg_table_size because this has a looser meaning that more easily includes indexes. An index doesn't really contain predicates and one doesn't store things in them directly. I think what's needed is a term that expresses the more inclusive or implementation-specific nature of the function that returns table + indexes + toast tables + kitchen sink. pg_tableall_size? pg_tablefull_size? pg_tableplus_size? pg_tableandmore_size? pg_tableimplementation_size? pg_tablekitchensink_size? ;) I recognize the desire to have a relatively short name for the functions, but perhaps a longer one is needed to capture the distinction between the two. (Though it's kind of frustrating that none of us have been able to hit on a term that accurately and succinctly describes it.) Michael Glaesemann grzm myrealbox com
Bruce Momjian wrote: > Andreas Pflug wrote: > >>Dave Page wrote: >> >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] >>>>Sent: 02 July 2005 21:30 >>>>To: Bruce Momjian >>>>Cc: Dave Page; PostgreSQL-patches; PostgreSQL-development >>>>Subject: Re: [PATCHES] Dbsize backend integration >>>> >>>> >>>>Is a new version of this patch coming? >>> >>> >>>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. > > > Hmm. I don't see how we can call it pg_table_size because people think > of tables and indexes, while relation has a more inclusive suggestion. We could, taking the same logic as GRANT which uses the keyword TABLE for sequences and Indexes too, but it's certainly not favourable. > > As far as pg_dbfile_size, do you have any other idea for a name? To me, > it returns the size of the 'db file' associated with the > heap/index/toast. How about pg_relation_size(oid, bool) with the second optional parameter to count all additional objects too (the 'total' flag). Regards, Andreas
On 7/3/05, Andreas Pflug <pgadmin@pse-consulting.de> 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
Dawid Kuroczko <qnex42@gmail.com> writes:
> Oh, I think pg_dbfile_size is best so far.
I think it's by far the ugliest suggestion yet :-(
Andreas's suggestion of having just one function with a bool parameter
might be a workable compromise.
regards, tom lane