eSQL-development
> > Subject: Re: [HACKERS] [PATCHES] Dbsize backend integration
> >
> > Tom Lane wrote:
> > >
> > > pg_relation_size plus pg_complete_relation_size is fine. Ship it...
> >
> > OK.
>
> Updated version attached.
>
> Regards
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> Sent: 06 July 2005 04:11
> To: Tom Lane
> Cc: Dave Page; Christopher Kings-Lynne; Robert Treat; Dawid
> Kuroczko; Andreas Pflug; PostgreSQL-patches; PostgreSQL-development
> Subject: Re: [HACK
Tom Lane wrote:
> Bruce Momjian 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 fit
Bruce Momjian 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 ca
Tom Lane wrote:
> Bruce Momjian 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
Bruce Momjian 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
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
> >
> -Original Message-
> From: Christopher Kings-Lynne [mailto:[EMAIL PROTECTED]
> 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: [HACK
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.
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,
> > t
> -Original Message-
> From: Robert Treat [mailto:[EMAIL PROTECTED]
> Sent: 04 July 2005 18:21
> To: Dave Page
> Cc: Tom Lane; Dawid Kuroczko; Andreas Pflug; Bruce Momjian;
> PostgreSQL-patches; PostgreSQL-development
> Subject: Re: [HACKERS] [PATCHES] Dbsiz
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
evelopment
> > Subject: Re: [HACKERS] [PATCHES] Dbsize backend integration
> >
> > "Dave Page" writes:
> > > Aside from the fact that's a change to the API that we had
> >
> > settled on,
> >
> > > it doesn't solve
Bruce Momjian wrote:
> Tom Lane wrote:
> > "Dave Page" writes:
> > > Aside from the fact that's a change to the API that we had settled on,
> > > it doesn't solve the actual problem of needing a suitable name for a
> > > function that returns the size of a table /or/ index. pg_relation_size()
> >
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: 04 July 2005 14:54
> To: Dave Page
> Cc: Dawid Kuroczko; Andreas Pflug; Bruce Momjian;
> PostgreSQL-patches; PostgreSQL-development
> Subject: Re: [HACKERS] [PATCHES] Dbsize backend integra
Tom Lane wrote:
> "Dave Page" writes:
> > Aside from the fact that's a change to the API that we had settled on,
> > it doesn't solve the actual problem of needing a suitable name for a
> > function that returns the size of a table /or/ index. pg_relation_size()
> > or pg_table_size() can't be use
"Dave Page" writes:
> Aside from the fact that's a change to the API that we had settled on,
> it doesn't solve the actual problem of needing a suitable name for a
> function that returns the size of a table /or/ index. pg_relation_size()
> or pg_table_size() can't be used for precisely the reason
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: 03 July 2005 17:10
> To: Dawid Kuroczko
> Cc: Andreas Pflug; Dave Page; Bruce Momjian;
> PostgreSQL-patches; PostgreSQL-development
> Subject: Re: [HACKERS] [PATCHES] Dbsize backend in
Dawid Kuroczko <[EMAIL PROTECTED]> writes:
> Oh, I think pg_dbfile_size is best so far.
I think it's by far the ugliest suggestion yet :-(
Andreas's suggestion of having just one function with a bool parameter
might be a workable compromise.
regards, tom lane
---
On 7/3/05, Andreas Pflug <[EMAIL PROTECTED]> wrote:
> > Yup, attached. Per our earlier conversation, pg_dbfile_size() now
> > returns the size of a table or index, and pg_relation_size() returns the
> > total size of a relation and all associated indexes and toast tables
> > etc.
>
> pg_relation_s
Bruce Momjian wrote:
Andreas Pflug wrote:
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
On Jul 3, 2005, at 8:35 AM, Bruce Momjian wrote:
Andreas Pflug wrote:
Dave Page wrote:
Yup, attached. Per our earlier conversation, pg_dbfile_size() now
returns the size of a table or index, and pg_relation_size()
returns the
total size of a relation and all associated indexes and toast
Andreas Pflug wrote:
> 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
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
Bruce Momjian writes:
> I don't think so. I think trait and property suggests an aspect of the
> object, so saying trait/property size is saying I am talking about an
> aspect of the object, while for a heap, its size is really its size, it
> isn't an aspect of its size.
I haven't been followi
[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().
Andreas Pflug <[EMAIL PROTECTED]> writes:
> I'm not really happy that all functions change their names (more
> versioning handling in pgadmin), but pg_storage_size is certainly the
> most precise name.
Actually, it seems excessively imprecise to me: the name conveys nothing
at all to help you re
Bruce Momjian wrote:
Yea, but then we have toast and we would need another name. I suggested
pg_storage_size() because it relates to a storage unit (index, toast,
etc), and not a real object or relation.
I'm not really happy that all functions change their names (more
versioning handling i
Michael Paesold wrote:
> > Do we have to use pg_object_size? Is there a better name? Are
> > indexes/toasts even objects?
>
> Relation is not an ideal names, but I heard people talk about heap relation
> and index relation. Indexes and tables (and sequences) are treated in a
> similar way quit
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
Bruce Momjian wrote:
Dave Page wrote:
pg_relation_size(text) - Get relation size by name/schema.name
pg_relation_size(oid)- Get relation size by OID
pg_tablespace_size(name) - Get tablespace size by name
pg_tablespace_size(oid) - Get tablespace size by OID
pg_database_size(name) - Ge
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
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(name) - Get 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
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.
Regards,
Andreas
? GNUmakefile
? config.log
? config.status
? dbsize-backen
50 matches
Mail list logo
