Re: ToDo: show size of partitioned table - Mailing list pgsql-hackers

Hi,

On 2019/02/07 18:08, Pavel Stehule wrote:
> čt 7. 2. 2019 v 9:51 odesílatel Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
>> \dPn seems to work fine, but I don't quite understand why \dPn+ should
>> show the sizes only for nested partitions of level.  Consider the

(correcting words of my previous email: ... of level 1.)

> Show nested objects in rectangular output is a problem. I prefer a design
> where any times the sum of displayed sizes is same like total size.
>
> So if I have partitions on level1 of size 16KB, and on level 2 8KB, then I
> would to display 16 and 8, and not 24 and 8. If I remember, this rule is
> modified, when filter is used.

Just to recap, the originally proposed feature is to show the size of a
partitioned table by summing the sizes of *all* of its (actually leaf)
partitions, which \dP[t|i]+ gives us.  As you mentioned, a limitation of
the feature as initially proposed is that it only shows partitioned tables
that are roots of their respective partition trees.  That is, there is no
way to see the sizes of the intermediate partitioned tables using any of
psql's \d commands.  So, you introduced the "n" modifier, whereby
\dP[t|i]n+ now shows *also* the intermediate partitioned tables with their
sizes.  But it only considers the directly attached partitions of each
partitioned table that's shown.  So, only those partitioned tables that
have leaf partitions directly attached them are shown with non-0 size (if
leaf partitions are non-empty) and others with size 0 (root partitioned
tables in most cases where nested partitioned tables are involved).  But I
think that means the "n" modifier is changing the behavior of the base
command (\dP+) which is meant to show the total size of *all* partitions
under a given partitioned table.  Maybe, the "n" modifier should only
result in including the nested/intermediate partitioned tables and nothing
more than that.

I see your point that all these tables are appearing in the display as one
flat list and so the sizes of same leaf partitions may be multiply
counted, but it's not totally a flat representation given that you have
added "Parent name" column.  We could document that the size of a nested
partitioned table shown in the display is also counted in the size of its
parent partitioned table.  That I think may be easier to understand than
that the size of each partitioned table shown in the display only
considers the sizes of leaf partitions that are directly attached to it.

Thoughts? Any more opinions on this?

Thanks,
Amit