Skip site navigation (1) Skip section navigation (2)

Re: Dbsize backend integration

From: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
To: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: "PostgreSQL-patches" <pgsql-patches(at)postgresql(dot)org>,"PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Dbsize backend integration
Date: 2005-06-29 10:17:22
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches

-----Original Message-----
From: Bruce Momjian [mailto:pgman(at)candle(dot)pha(dot)pa(dot)us]
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 of them.  I am not sure that makes sense because we usually equate
> relation with table, and an index isn't a relation, really.

Err, yes - posted that before I got your reply!

> Do we have to use pg_object_size?  Is there a better name?  Are
> indexes/toasts even objects?

Yeah, I think perhaps pg_object_size is better in some ways than pg_relation_size, however I stuck with relation because (certainly in pgAdmin world) we tend to think of pretty much anything as an object. I could go either way on that though, however Michael doesn't seem so keen.

So, one for pg_object_size, one on the fench and one against :-). Anyone else got a preference?

Regards, Dave.


pgsql-hackers by date

Next:From: Teodor SigaevDate: 2005-06-29 10:43:11
Subject: Re: GiST concurrency commited
Previous:From: Qingqing ZhouDate: 2005-06-29 10:09:34
Subject: Re: GiST concurrency commited

pgsql-patches by date

Next:From: Bruce MomjianDate: 2005-06-29 11:45:44
Subject: Re: Dbsize backend integration
Previous:From: Abhijit Menon-SenDate: 2005-06-29 09:47:31
Subject: spi_query/spi_fetchrow for pl/perl

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group