Re: partition tree inspection functions - Mailing list pgsql-hackers

From Amit Langote
Subject Re: partition tree inspection functions
Date
Msg-id 5686970f-b4e8-bbe5-9109-b97763714c19@lab.ntt.co.jp
Whole thread Raw
In response to Re: partition tree inspection functions  (Jesper Pedersen <jesper.pedersen@redhat.com>)
Responses Re: partition tree inspection functions  (Jesper Pedersen <jesper.pedersen@redhat.com>)
List pgsql-hackers
Hi Jesper,

On 2018/07/19 23:18, Jesper Pedersen wrote:
> I'm thinking about how to best use these functions to generate a graph
> that represents the partition hierarchy.
> 
> What about renaming pg_partition_tree_tables() to pg_partition_children(),
> and have it work like
> 
> select * from pg_partition_children('p', true);
> ---------
>  p
>  p0
>  p1
>  p00
>  p01
>  p10
>  p11
> (7 rows)
> 
> select * from pg_partition_children('p', false);
> ---------
>  p0
>  p1
> (2 rows)
> 
> e.g. if 'bool include_all' is true all nodes under the node, including
> itself, are fetched. With false only nodes directly under the node,
> excluding itself, are returned. If there are no children NULL is returned.

That's a big change to make to what this function does, but if that's
what's useful we could make it.  As an alternative, wouldn't it help to
implement the idea that Dilip mentioned upthread of providing a function
to report the level of a given table in the partition hierarchy -- 0 for
root, 1 for its partitions and so on?

Basically, as also discussed before, users can already use SQL to get the
information they want out of the relevant catalogs (pg_inherits, etc.).
But, such user queries might not be very future-proof as we might want to
change the catalog organization in the future, so we'd like to provide
users a proper interface to begin with.  Keeping that in mind, it'd be
better to think carefully about what we ought to be doing here.  Input
like yours is greatly helpful for that.

>>> Maybe a function like pg_partition_number_of_partitions() could be of
>>> benefit to count the number of actual partitions in a tree. Especially
>>> useful in complex scenarios,
>>>
>>>   select pg_partition_number_of_partitions('p') as number;
>>>
>>>     number
>>>   ---------
>>>    4
>>>   (1 row)
>>
>> Okay, adding one more function at this point may not be asking for too
>> much.  Although, select count(*) from pg_partition_tree_tables('p') would
>> give you the count, a special function seems nice.
> 
> Yeah, but I was thinking that the function would only return the number of
> actual tables that contains data, e.g. not include 'p', 'p0' and 'p1' in
> the count; otherwise you could use 'select count(*) from
> pg_partition_children('p', true)' like you said.

Maybe call it pg_partition_tree_leaf_count() or some such then?

Thanks,
Amit



pgsql-hackers by date:

Previous
From: Karen Huddleston
Date:
Subject: Re: Making "COPY partitioned_table FROM" faster
Next
From: Mithun Cy
Date:
Subject: Re: Possible performance regression in version 10.1 with pgbenchread-write tests.