Dave Page wrote:
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 02 July 2005 21:30
To: Bruce Momjian
Cc: Dave Page; PostgreSQL-patches; PostgreSQL-development
Subject: Re: [PATCHES] Dbsize backend integration
Is a new version of this patch coming?
Yup
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> Sent: 02 July 2005 21:30
> To: Bruce Momjian
> Cc: Dave Page; PostgreSQL-patches; PostgreSQL-development
> Subject: Re: [PATCHES] Dbsize backend integration
>
>
> Is a new version
t: 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 ma
[EMAIL PROTECTED] wrote:
> > > I have a new idea --- pg_storage_size().
> >
> > I'm not against that one, but I think Tom's point is vaild. I cannot
> > think of anything better at the moment though (maybe pg_component_size,
> > but that's equally random) :-(
> >
> > Anyone else? Please? Someone
Dave Page wrote:
> > 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.
>
> The totalling version (whatever it ends up being called) should
> definitely work on toast tables, as it is a legitimate use case to
"Dave Page" writes:
>> I've not been following the thread closely, so maybe this was already
>> proposed and rejected, but what about:
>> [4 functions]
> That moves the goal posts somewhat.
Fair enough. The two you described are OK by me.
regards, tom lane
---
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: 30 June 2005 14:41
> To: Dave Page
> Cc: Michael Glaesemann; PostgreSQL-patches; PostgreSQL-development
> Subject: Re: [PATCHES] Dbsize backend integration
>
> "Dave Page" wri
"Dave Page" writes:
> Thanks Michael. We have 2 functions - 1 returns the on disk size of a
> table or index without any additional parts such as indexes or toast
> tables. The other function returns the total on disk size of a table and
> all associated indexes and toast tables (and any indexes t
> -Original Message-
> From: Michael Glaesemann [mailto:[EMAIL PROTECTED]
> Sent: 30 June 2005 10:01
> To: Dave Page
> Cc: PostgreSQL-patches; PostgreSQL-development
> Subject: Re: [PATCHES] Dbsize backend integration
>
>
> I'm still unclear as
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: 30 June 2005 10:29
> To: Bruce Momjian; Dave Page
> Cc: PostgreSQL-patches; PostgreSQL-development
> Subject: Re: [PATCHES] Dbsize backend integration
>
>
> Maybe pg_trait
> > I have a new idea --- pg_storage_size().
>
> I'm not against that one, but I think Tom's point is vaild. I cannot
> think of anything better at the moment though (maybe pg_component_size,
> but that's equally random) :-(
>
> Anyone else? Please? Someone? Anyone? :-)
Maybe pg_trait_size() or
On Jun 30, 2005, at 5:48 PM, Dave Page wrote:
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 29 June 2005 12:46
I have a new idea --- pg_storage_size().
I'm not against that one, but I think Tom's point is vaild. I cannot
think of anything better at the mo
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> Sent: 29 June 2005 12:46
> To: Dave Page
> Cc: PostgreSQL-patches; PostgreSQL-development
> Subject: Re: [PATCHES] Dbsize backend integration
>
> I have a new idea --- pg_storage_size().
Dave Page wrote:
>
>
>
> -Original Message- From: Bruce Momjian
> [mailto:[EMAIL PROTECTED] 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 we
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
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
Dave Page wrote:
> The attached patch integrates dbsize functions into the backend, as per
> discussion on -hackers. The following functions are included:
>
> pg_relation_size(text) - Get relation size by name/schema.name
> pg_relation_size(oid)- Get relation size by OID
> pg_tablespace_size
If dbsize is being moved from contrib to the backend, it should be moved
in in its entirety ...
On Tue, 21 Jun 2005, Bruce Momjian wrote:
This version is being removed from the patches queue because it does not
address how to handle existing dbsize functions not moved into the main
server.
This version is being removed from the patches queue because it does not
address how to handle existing dbsize functions not moved into the main
server.
---
Andreas Pflug wrote:
> As a start for a bunch of instrumentation f
Bruce Momjian wrote:
Andreas Pflug wrote:
As a start for a bunch of instrumentation functions that should be
included in the backend as discussed previously, here are the dbsize
functions. The dbsize.c file should go to the usual place,
src/backend/utils/adt.
How does this related to /cont
Andreas Pflug wrote:
> As a start for a bunch of instrumentation functions that should be
> included in the backend as discussed previously, here are the dbsize
> functions. The dbsize.c file should go to the usual place,
> src/backend/utils/adt.
How does this related to /contrib/dbsize? You h
20 matches
Mail list logo
