SEO
vBulletin Search Engine Optimization
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
04-11-2008, 04:33 AM
| ||||
| ||||
 Re: DBSize backend integration > -----Original Message----- > From: Bruce Momjian [mailto  gman@candle.pha.pa.us]> Sent: 24 June 2005 21:07 > To: Dave Page > Cc: PostgreSQL-development > Subject: Re: [HACKERS] DBSize backend integration > > > > > > > So drop total_relation_size(), > relation_size_components(), and what > > > else? > > > > indexes_size() > > What is the logic for removing that? Because it is an > aggregate of all > indexes? Yes, and is of limited use in my opinion. I can see a use for pg_relation_size when used on an individual index, but the total of all indexes on a relation seems of little real use to me (and is relatively easily calculated if it really is required for a more specialised purpose). Regards, Dave. ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly      |
|
04-11-2008, 04:34 AM
| |||
| |||
| Re: DBSize backend integration Dave Page wrote: > > > > >>-----Original Message----- >>From: Bruce Momjian [mailto gman@candle.pha.pa.us]>>Sent: 24 June 2005 21:07 >>To: Dave Page >>Cc: PostgreSQL-development >>Subject: Re: [HACKERS] DBSize backend integration >> >> >> >>>>So drop total_relation_size(), >>>> >>>> >>relation_size_components(), and what >> >> >>>>else? >>>> >>>> >>>indexes_size() >>> >>> >>What is the logic for removing that? Because it is an >>aggregate of all >>indexes? >> >> > >Yes, and is of limited use in my opinion. I can see a use for >pg_relation_size when used on an individual index, but the total of all >indexes on a relation seems of little real use to me (and is relatively >easily calculated if it really is required for a more specialised >purpose). > > > [from memory] the relation_components function adds components in a questionable way, e.g. counting on index on the toast table as index. To me, that's internal implementation detail, and should be counted as toast table size too. Regards, Andreas ---------------------------(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 |
|
04-11-2008, 04:34 AM
| ||||
| ||||
| Re: DBSize backend integration Andreas Pflug wrote: > > > > > > > [from memory] the relation_components function adds components in a > questionable way, e.g. counting on index on the toast table as index. To > me, that's internal implementation detail, and should be counted as > toast table size too. Agreed. The user doesn't create the toast index like regular indexes. -- 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 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly |
 |
« Re: [BUGS] BUG #1467: fe_connect doesn't handle EINTR right
|
get_rel_* functions in lsyscache.c »
| Thread Tools | |
| Display Modes | |
Linear Mode
|
|
All times are GMT. The time now is 11:04 AM.
