Re: [HACKERS] Dbsize backend integration
От | Robert Treat |
---|---|
Тема | Re: [HACKERS] Dbsize backend integration |
Дата | |
Msg-id | 200507042134.17905.xzilla@users.sourceforge.net обсуждение исходный текст |
Ответ на | Re: [HACKERS] Dbsize backend integration (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] Dbsize backend integration
|
Список | pgsql-patches |
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
В списке pgsql-patches по дате отправления: