Re: [Sender Address Forgery]Re: pg_(total_)relation_size andpartitioned tables - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [Sender Address Forgery]Re: pg_(total_)relation_size andpartitioned tables
Date
Msg-id 20180122024407.GA1772@paquier.xyz
Whole thread Raw
In response to Re: [Sender Address Forgery]Re: pg_(total_)relation_size andpartitioned tables  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: [Sender Address Forgery]Re: pg_(total_)relation_size andpartitioned tables
List pgsql-hackers
On Sun, Jan 21, 2018 at 07:16:38PM +1300, David Rowley wrote:
> On 20 January 2018 at 23:14, Michael Paquier <michael.paquier@gmail.com> wrote:
>> If pg_partition_tree_tables() uses the top of the partition as input,
>> all the tree should show up. If you use a leaf, anything under the leaf
>> should show up. If a leaf is defined and it has no underlying leaves,
>> then only this outmost leaf should be listed.
>
> hmm, that's thoroughly confusing. Just in case anyone else is stuck on
> that, I just need to mention that a leaf is the does not have
> branches, in nature or computer science.

OK, sorry if my words are confusing. Imagine that you have the following
partition set:

       p
      / \
     /   \
    p1   p2
        /  \
       /    \
      p21   p22

If pg_partition_tree_tables() uses 'p' as input argument, then I would
imagine that it should return p, p1, p2, p21 and p22. If 'p2' is used,
then p2, p21 and p22 are the results. If either one of p1, p21 or p22 is
used as input, then the result is respectively p1, p21 or p22.

Amit's patch seems to be doing that kind of logic by using
find_all_inheritors, which is good. We need to make the difference
between relations that are part of a partition set and the other ones
which are part of an INHERIT link, and, at least it seems to me, the
patch is not careful with that. I haven't tested what is proposed
though, but this portion likely needs more thoughts.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)
Next
From: Thomas Munro
Date:
Subject: Re: Doc tweak for huge_pages?