Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fgL9A-0006z8-T6 for pgsql-hackers@arkaria.postgresql.org; Fri, 20 Jul 2018 02:27:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fgL96-0008N7-9P for pgsql-hackers@arkaria.postgresql.org; Fri, 20 Jul 2018 02:27:52 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fgL96-0008N0-2n for pgsql-hackers@lists.postgresql.org; Fri, 20 Jul 2018 02:27:52 +0000 Received: from tama50.ecl.ntt.co.jp ([129.60.39.147]) by magus.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fgL8w-00080i-Q9 for pgsql-hackers@postgresql.org; Fri, 20 Jul 2018 02:27:49 +0000 Received: from vc1.ecl.ntt.co.jp (vc1.ecl.ntt.co.jp [129.60.86.153]) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id w6K2RVHC004829; Fri, 20 Jul 2018 11:27:31 +0900 Received: from vc1.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id 0B131EA77FA; Fri, 20 Jul 2018 11:27:31 +0900 (JST) Received: from jcms-pop21.ecl.ntt.co.jp (jcms-pop21.ecl.ntt.co.jp [129.60.87.134]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id 00B14EA7550; Fri, 20 Jul 2018 11:27:31 +0900 (JST) Received: from [127.0.0.1] (unknown [129.60.241.61]) by jcms-pop21.ecl.ntt.co.jp (Postfix) with ESMTPSA id EFDC7400BE5; Fri, 20 Jul 2018 11:27:30 +0900 (JST) Subject: Re: partition tree inspection functions References: <8d00e51a-9a51-ad02-d53e-ba6bf50b2e52@lab.ntt.co.jp> <5a560c9c-3722-1914-f34b-1de0ff3310d1@lab.ntt.co.jp> <20180627121615.GF2667@paquier.xyz> <45e28062-976d-45bf-56f8-9746f551da02@lab.ntt.co.jp> <20180628034341.GH11054@paquier.xyz> <6baeb45a-6222-6b88-342d-37fc7d3cf89a@lab.ntt.co.jp> <4f4a2518-6c62-5463-6ac2-1241ae9d6041@redhat.com> <38183355-ea7c-9443-0c38-6124fcf5f38b@redhat.com> From: Amit Langote Message-ID: <5686970f-b4e8-bbe5-9109-b97763714c19@lab.ntt.co.jp> Date: Fri, 20 Jul 2018 11:27:11 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: <38183355-ea7c-9443-0c38-6124fcf5f38b@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit X-CC-Mail-RelayStamp: 1 To: jesper.pedersen@redhat.com Cc: Michael Paquier , Jeevan Ladhe , Pg Hackers X-TM-AS-MML: disable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk 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