-----Original Message-----
From: Bruce Momjian [mailtogman@candle.pha.pa.us]
Sent: Wed 6/29/2005 2:16 AM
To: Dave Page
Cc: PostgreSQL-patches; PostgreSQL-development
Subject: Re: [PATCHES] Dbsize backend integration

> OK, so you went with relation as heap/index/toast only, and table as the
> total of them. I am not sure that makes sense because we usually equate
> relation with table, and an index isn't a relation, really.

Err, yes - posted that before I got your reply!

> Do we have to use pg_object_size? Is there a better name? Are
> indexes/toasts even objects?

Yeah, I think perhaps pg_object_size is better in some ways than pg_relation_size, however I stuck with relation because (certainly in pgAdmin world) we tend to think of pretty much anything as an object. I could go either way on that though, however Michael doesn't seem so keen.

So, one for pg_object_size, one on the fench and one against :-). Anyone else got a preference?

Regards, Dave.

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Dave Page wrote:
>
>
>
> -----Original Message----- From: Bruce Momjian
> [mailtogman@candle.pha.pa.us] Sent: Wed 6/29/2005 2:16 AM To: Dave
> Page Cc: PostgreSQL-patches; PostgreSQL-development Subject: Re:
> [PATCHES] Dbsize backend integration
>
> > OK, so you went with relation as heap/index/toast only, and table as the
> > total of them. I am not sure that makes sense because we usually equate
> > relation with table, and an index isn't a relation, really.
>
> Err, yes - posted that before I got your reply!
>
> > Do we have to use pg_object_size? Is there a better name? Are
> > indexes/toasts even objects?
>
> Yeah, I think perhaps pg_object_size is better in some ways than
> pg_relation_size, however I stuck with relation because (certainly in
> pgAdmin world) we tend to think of pretty much anything as an object.
> I could go either way on that though, however Michael doesn't seem so
> keen.
>
> So, one for pg_object_size, one on the fench and one against :-). Anyone
> else got a preference?

I have a new idea --- pg_storage_size(). That would do just the
toast/index/heap, and pg_relation_size() gets a total of them all, and
only works on heap, no index or toast.

How is that?

--
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 4: Don't 'kill -9' the postmaster

Is a new version of this patch coming?

---------------------------------------------------------------------------

Bruce Momjian wrote:
> Dave Page wrote:
> >
> >
> >
> > -----Original Message----- From: Bruce Momjian
> > [mailtogman@candle.pha.pa.us] Sent: Wed 6/29/2005 2:16 AM To: Dave
> > Page Cc: PostgreSQL-patches; PostgreSQL-development Subject: Re:
> > [PATCHES] Dbsize backend integration
> >
> > > OK, so you went with relation as heap/index/toast only, and table as the
> > > total of them. I am not sure that makes sense because we usually equate
> > > relation with table, and an index isn't a relation, really.
> >
> > Err, yes - posted that before I got your reply!
> >
> > > Do we have to use pg_object_size? Is there a better name? Are
> > > indexes/toasts even objects?
> >
> > Yeah, I think perhaps pg_object_size is better in some ways than
> > pg_relation_size, however I stuck with relation because (certainly in
> > pgAdmin world) we tend to think of pretty much anything as an object.
> > I could go either way on that though, however Michael doesn't seem so
> > keen.
> >
> > So, one for pg_object_size, one on the fench and one against :-). Anyone
> > else got a preference?
>
> I have a new idea --- pg_storage_size(). That would do just the
> toast/index/heap, and pg_relation_size() gets a total of them all, and
> only works on heap, no index or toast.
>
> How is that?
>
> --
> 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 4: Don't 'kill -9' the postmaster
>

--
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 1: subscribe and unsubscribe commands go to majordomo@postgresql.org