Thread: Re: [PATCHES] Dbsize backend integration
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: 04 July 2005 14:54 > To: Dave Page > Cc: Dawid Kuroczko; Andreas Pflug; Bruce Momjian; > PostgreSQL-patches; PostgreSQL-development > Subject: Re: [HACKERS] [PATCHES] Dbsize backend integration > > "Dave Page" <dpage@vale-housing.co.uk> writes: > > Aside from the fact that's a change to the API that we had > settled on, > > it doesn't solve the actual problem of needing a suitable name for a > > function that returns the size of a table /or/ index. > pg_relation_size() > > or pg_table_size() can't be used for precisely the reason they were > > rejected for that purpose in the first place. > > Rejected by whom? pg_relation_size is an excellent choice for that. Bruce didn't like it (http://archives.postgresql.org/pgsql-hackers/2005-06/msg01410.php), and you seemed to object as well (http://archives.postgresql.org/pgsql-hackers/2005-06/msg01247.php) Personally I'm beyond caring much now as the amount of time spent trying to name these simple functions is wildly disproportionate the the effort take to actually code them. I think we just need to agree there is no perfect name and rely on the comments and docs to guide people. I think the current names work OK, and Bruce and Dawid at least agree! Regards, Dave.
On Monday 04 July 2005 10:11, Dave Page wrote: > > -----Original Message----- > > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > > Sent: 04 July 2005 14:54 > > To: Dave Page > > Cc: Dawid Kuroczko; Andreas Pflug; Bruce Momjian; > > PostgreSQL-patches; PostgreSQL-development > > Subject: Re: [HACKERS] [PATCHES] Dbsize backend integration > > > > "Dave Page" <dpage@vale-housing.co.uk> writes: > > > Aside from the fact that's a change to the API that we had > > > > settled on, > > > > > it doesn't solve the actual problem of needing a suitable name for a > > > function that returns the size of a table /or/ index. > > > > pg_relation_size() > > > > > or pg_table_size() can't be used for precisely the reason they were > > > rejected for that purpose in the first place. > > > > Rejected by whom? pg_relation_size is an excellent choice for that. > > Bruce didn't like it > (http://archives.postgresql.org/pgsql-hackers/2005-06/msg01410.php), and > you seemed to object as well > (http://archives.postgresql.org/pgsql-hackers/2005-06/msg01247.php) > > Personally I'm beyond caring much now as the amount of time spent trying > to name these simple functions is wildly disproportionate the the effort > take to actually code them. I think we just need to agree there is no > perfect name and rely on the comments and docs to guide people. I think > the current names work OK, and Bruce and Dawid at least agree! > Actually I'd agree with Tom, pg_dbfile_size is ugly, and suggest to me I could use a filename as an argument. ISTM that if we think that functions like pg_database_size and pg_tablespace_size all make sense, the natural extension would be functions called pg_index_size to tell us the size of an index, pg_table_size to tell us the size of a table (table+toast) without it's indexes, and some form of pg_table_plus_indexes_size for a table and its indexes for those that feel we need both. I'm not sold we need a function that can return either an index or table size, but if so something like pg_object_size seems ambigious enough to work, and is future proof enough to handle things like materialized views when and if they arise. Just my .02 :-) -- Robert Treat Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Robert Treat wrote: > Actually I'd agree with Tom, pg_dbfile_size is ugly, and suggest to me I could > use a filename as an argument. ISTM that if we think that functions like > pg_database_size and pg_tablespace_size all make sense, the natural extension > would be functions called pg_index_size to tell us the size of an index, > pg_table_size to tell us the size of a table (table+toast) without it's > indexes, and some form of pg_table_plus_indexes_size for a table and its > indexes for those that feel we need both. I'm not sold we need a function > that can return either an index or table size, but if so something like > pg_object_size seems ambigious enough to work, and is future proof enough to > handle things like materialized views when and if they arise. You are into the cycle we were in. We discussed pg_object size (too vague) and pg_index_size (needs pg_toast_size too, and maybe toast indexes; too many functions). -- 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 Monday 04 July 2005 13:25, Bruce Momjian wrote:
> Robert Treat wrote:
> > Actually I'd agree with Tom, pg_dbfile_size is ugly, and suggest to me I
> > could use a filename as an argument. ISTM that if we think that
> > functions like pg_database_size and pg_tablespace_size all make sense,
> > the natural extension would be functions called pg_index_size to tell us
> > the size of an index, pg_table_size to tell us the size of a table
> > (table+toast) without it's indexes, and some form of
> > pg_table_plus_indexes_size for a table and its indexes for those that
> > feel we need both. I'm not sold we need a function that can return
> > either an index or table size, but if so something like pg_object_size
> > seems ambigious enough to work, and is future proof enough to handle
> > things like materialized views when and if they arise.
>
> You are into the cycle we were in. We discussed pg_object size (too
> vague) and pg_index_size (needs pg_toast_size too, and maybe toast
> indexes; too many functions).
Yeah, I read those discussions, and think you were better off then than you
are now, which is why I went back to it somewhat.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
>>You are into the cycle we were in. We discussed pg_object size (too >>vague) and pg_index_size (needs pg_toast_size too, and maybe toast >>indexes; too many functions). > > Yeah, I read those discussions, and think you were better off then than you > are now, which is why I went back to it somewhat. To be honest, the amount of effort being expended on this naming discussion far outweighs the benefits. Maybe it's time for a core member to step in and just resolve it - one way or the other? Chris