> > On Thu, 2005-01-27 at 08:05 +0100, Michael Paesold wrote:
> > > Perhaps you could rename indices_size to indexes_size.
>
> Attached patch identical except for s/indices/indexes/g.

Attached is the same patch as context diff. (prior send from unregistered
email address)

Ed





---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

> > On Thu, 2005-01-27 at 08:05 +0100, Michael Paesold wrote:
> > > Perhaps you could rename indices_size to indexes_size.
>
> Attached patch identical except for s/indices/indexes/g.

Attached is the same patch as context diff.

Ed



---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

If the C code for the prior dbsize patch is not acceptable for whatever
reason, here's a SQL-based patch to replace it. It's not a drop-in for
7.3/7.4 as I'd hoped, only an 8.1 patch. I believe it is functionally
equivalent to the C patch, but simpler, shorter, and probably a tad slower.
I also removed the README section on how to aggregate since it was
incomplete/incorrect (it didn't count toasted indices) and added a SQL
function that itemizes the size for a relation's table and index data
(helpful to us in identifying bloat, measuring performance, capacity
estimation, etc).

Ed


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Neil, do you have a verdict on this patch?

On Friday January 28 2005 10:30, Ed L. wrote:
> If the C code for the prior dbsize patch is not acceptable for
> whatever reason, here's a SQL-based patch to replace it. It's
> not a drop-in for 7.3/7.4 as I'd hoped, only an 8.1 patch. I
> believe it is functionally equivalent to the C patch, but
> simpler, shorter, and probably a tad slower. I also removed
> the README section on how to aggregate since it was
> incomplete/incorrect (it didn't count toasted indices) and
> added a SQL function that itemizes the size for a relation's
> table and index data (helpful to us in identifying bloat,
> measuring performance, capacity estimation, etc).
>
> Ed


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

On Thursday February 3 2005 9:23, Ed L. wrote:
> Neil, do you have a verdict on this patch?
>
> On Friday January 28 2005 10:30, Ed L. wrote:
> > If the C code for the prior dbsize patch is not acceptable
> > for whatever reason, here's a SQL-based patch to replace it.

I submitted a dbsize patch on Jan 25, revised it twice per
concerns raised by Michael Paesold and Neil Conway ("indexes"
instead of "indices") and Andreas Pflug and Tom Lane (implement
in SQL instead of C) and resubmitted Jan 28. I've not received
any further communication regarding the patch. Please advise if
there are concerns. I've attached the patch again, slightly
cleaned up, in case it has fallen through the cracks.

Ed


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

It is still in my mailbox for review. Sorry.

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

Ed L. wrote:
> On Thursday February 3 2005 9:23, Ed L. wrote:
> > Neil, do you have a verdict on this patch?
> >
> > On Friday January 28 2005 10:30, Ed L. wrote:
> > > If the C code for the prior dbsize patch is not acceptable
> > > for whatever reason, here's a SQL-based patch to replace it.
>
> I submitted a dbsize patch on Jan 25, revised it twice per
> concerns raised by Michael Paesold and Neil Conway ("indexes"
> instead of "indices") and Andreas Pflug and Tom Lane (implement
> in SQL instead of C) and resubmitted Jan 28. I've not received
> any further communication regarding the patch. Please advise if
> there are concerns. I've attached the patch again, slightly
> cleaned up, in case it has fallen through the cracks.
>
> Ed

[ Attachment, skipping... ]

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

--
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 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

Patch applied. Thanks.

I renamed aggregate_relation_size() to total_relation_size(). To me
'aggregate' was too closely associated with 'aggregates'. If you have
improved wording please let me know.

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


Ed L. wrote:
> On Thursday February 3 2005 9:23, Ed L. wrote:
> > Neil, do you have a verdict on this patch?
> >
> > On Friday January 28 2005 10:30, Ed L. wrote:
> > > If the C code for the prior dbsize patch is not acceptable
> > > for whatever reason, here's a SQL-based patch to replace it.
>
> I submitted a dbsize patch on Jan 25, revised it twice per
> concerns raised by Michael Paesold and Neil Conway ("indexes"
> instead of "indices") and Andreas Pflug and Tom Lane (implement
> in SQL instead of C) and resubmitted Jan 28. I've not received
> any further communication regarding the patch. Please advise if
> there are concerns. I've attached the patch again, slightly
> cleaned up, in case it has fallen through the cracks.
>
> Ed

[ Attachment, skipping... ]

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

--
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 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match