Thread: Re: [PATCHES] Dbsize backend integration
> -----Original Message----- > From: Christopher Kings-Lynne [mailto:chriskl@familyhealth.com.au] > Sent: 05 July 2005 02:39 > To: Robert Treat > Cc: Bruce Momjian; Dave Page; Tom Lane; Dawid Kuroczko; > Andreas Pflug; PostgreSQL-patches; PostgreSQL-development > Subject: Re: [HACKERS] [PATCHES] Dbsize backend integration > > >>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? Agreed. The current names were discussed (at some length!) by Bruce & I before I reworked the latest version of the patch. Can we just settle on that? Regards, Dave.
Dave Page wrote: > > >>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? > > Agreed. The current names were discussed (at some length!) by Bruce & I > before I reworked the latest version of the patch. Can we just settle on > that? If we go pg_table_size() and pg_relation_size(), which is object-only and which is heap + index + toast? I think ideally we want pg_relation_size to be the combined one, but then we have pg_table_size that works on indexes and toast too, and that is confusing, and we don't want to add index and toast versions. Or is an index a relation? And TOAST? OK, how about pg_relation_size for heap/index/toast, and pg_complete_relation_size for the combined total. -- 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
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> If we go pg_table_size() and pg_relation_size(), which is object-only
> and which is heap + index + toast? I think ideally we want
> pg_relation_size to be the combined one, but then we have pg_table_size
> that works on indexes and toast too, and that is confusing, and we don't
> want to add index and toast versions. Or is an index a relation? And
> TOAST?
All the backend code thinks so --- anything that has an entry in
pg_class is a relation. So personally I don't find "table" and
"relation" confusing in this context. But I can see it might be
confusing to people not familiar with PG jargon.
> OK, how about pg_relation_size for heap/index/toast, and
> pg_complete_relation_size for the combined total.
I could live with that. Or "pg_total_relation_size".
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > If we go pg_table_size() and pg_relation_size(), which is object-only > > and which is heap + index + toast? I think ideally we want > > pg_relation_size to be the combined one, but then we have pg_table_size > > that works on indexes and toast too, and that is confusing, and we don't > > want to add index and toast versions. Or is an index a relation? And > > TOAST? > > All the backend code thinks so --- anything that has an entry in > pg_class is a relation. So personally I don't find "table" and > "relation" confusing in this context. But I can see it might be > confusing to people not familiar with PG jargon. > > > OK, how about pg_relation_size for heap/index/toast, and > > pg_complete_relation_size for the combined total. > > I could live with that. Or "pg_total_relation_size". The problem with "total", to me, is that it already is the total size of the heap/index/toast. Complete has the idea of adding additional pieces, which I think fits best. -- 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
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> I could live with that. Or "pg_total_relation_size".
> The problem with "total", to me, is that it already is the total size of
> the heap/index/toast. Complete has the idea of adding additional
> pieces, which I think fits best.
[ shrug ] I don't care --- if you do, then do that.
I finally realized exactly what was bugging me about "dbfile_size": it
seems to imply that we are measuring the size of one *file*, which is
under no circumstance the definition of any of these functions (see
file splitting behavior for relations exceeding 1GB).
pg_relation_size plus pg_complete_relation_size is fine. Ship it...
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Tom Lane wrote: > >> I could live with that. Or "pg_total_relation_size". > > > The problem with "total", to me, is that it already is the total size of > > the heap/index/toast. Complete has the idea of adding additional > > pieces, which I think fits best. > > [ shrug ] I don't care --- if you do, then do that. > > I finally realized exactly what was bugging me about "dbfile_size": it > seems to imply that we are measuring the size of one *file*, which is > under no circumstance the definition of any of these functions (see > file splitting behavior for relations exceeding 1GB). Yes, that is an issue I considered. I was more relying on the _idea_ that people thought it was a single file, but that is an implementation detail that shouldn't be promoted. > pg_relation_size plus pg_complete_relation_size is fine. Ship it... OK. -- 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