: 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
-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, attached. Per
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: 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().
I'm not against that one, but I
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
snip /
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
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
-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_size() or pg_property_size() will do?
I
-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 to what exactly is trying to be captured
Dave Page dpage@vale-housing.co.uk 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
Dave Page dpage@vale-housing.co.uk 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
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 want
[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? Anyone? :-)
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 went with relation as heap/index/toast only
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
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.
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 have
16 matches
Mail list logo
