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
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
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
-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 the
> total
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/to
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
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
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
"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: 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,
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: 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
> > 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() wil
"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: 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" writes:
> > Thanks Michael. We have 2 fu
On 6/30/05, Dave Page wrote:
> > -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_sto
Dawid Kuroczko wrote:
On 6/30/05, Dave Page wrote:
-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_
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
[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
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
> -Original Message-
> From: Dawid Kuroczko [mailto:[EMAIL PROTECTED]
> Sent: 30 June 2005 22:21
> To: Dave Page
> Cc: PostgreSQL-development
> Subject: Re: [HACKERS] [PATCHES] Dbsize backend integration
>
> On 6/30/05, Dave Page wrote:
> > >
Is a new version of this patch coming?
---
Bruce Momjian wrote:
> Dave Page wrote:
> >
> >
> >
> > -Original Message- From: Bruce Momjian
> > [mailto:[EMAIL PROTECTED] Sent: Wed 6/29/2005 2:16 AM To: Dave
> > Page
> -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, attach
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,
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 integr
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
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
I
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
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
---
> -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
"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
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
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
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
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
> -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
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
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.
> -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
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
> >
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
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:
> 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:
> > 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
> -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
47 matches
Mail list logo
