From: | Bernd Helmle <mailings(at)oopsware(dot)de> |
---|---|
To: | Greg Smith <greg(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Rafael Martinez <r(dot)m(dot)guerrero(at)usit(dot)uio(dot)no>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Table size does not include toast size |
Date: | 2009-12-22 14:11:40 |
Message-ID: | FA73A1E87E9C2F1C6C1DF660@[172.26.14.62] |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
--On 21. Dezember 2009 12:02:02 -0500 Greg Smith <greg(at)2ndquadrant(dot)com>
wrote:
> Tom Lane wrote:
>> Perhaps invent pg_table_size() = base table + toast table + toast index
>> and pg_indexes_size() = all other indexes for table
>> giving us the property pg_table_size + pg_indexes_size =
>> pg_total_relation_size
>>
> Right; that's exactly the way I'm computing things now, I just have to
> crawl way too much catalog data to do it. I also agree that if we
> provide pg_table_size, the issue of "pg_relation_size doesn't do what I
> want" goes away without needing to even change the existing
> documentation--people don't come to that section looking for "relation",
> they're looking for "table".
>
> Bernd, there's a basic spec if you have time to work on this.
I see if i can get some time for it during christmas vacation (its on my
radar for a longer period of time). I'm still working on this NOT NULL
pg_constraint representation and would like to propose a patch fairly soon
for this.
--
Thanks
Bernd
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2009-12-22 14:21:10 | Re: Streaming replication and non-blocking I/O |
Previous Message | Bernd Helmle | 2009-12-22 14:09:42 | Re: Table size does not include toast size |