From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | Greg Smith <greg(at)2ndquadrant(dot)com>, Bernd Helmle <mailings(at)oopsware(dot)de>, 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-21 18:11:25 |
Message-ID: | 18004.1261419085@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Stark <gsstark(at)mit(dot)edu> writes:
> On Mon, Dec 21, 2009 at 5:02 PM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
>> 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.
> What about, the visibility maps and free space maps?
Those would be included for each relation, I should think. The
objective here is not to break things down even more finely than
pg_relation_size does, but to aggregate into terms that are meaningful
to the user --- which is to say, "the table" and "its indexes".
Anything you can't get rid of by dropping indexes/constraints is
part of "the table" at this level of detail.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-12-21 18:21:28 | Re: Streaming replication and non-blocking I/O |
Previous Message | Greg Stark | 2009-12-21 18:01:54 | Re: Table size does not include toast size |