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 1fg9lm-0004Dh-NZ for pgsql-hackers@arkaria.postgresql.org; Thu, 19 Jul 2018 14:19:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fg9lk-0000zw-M4 for pgsql-hackers@arkaria.postgresql.org; Thu, 19 Jul 2018 14:19:00 +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 1fg9lk-0000zp-Ex for pgsql-hackers@lists.postgresql.org; Thu, 19 Jul 2018 14:19:00 +0000 Received: from mail-qt0-f175.google.com ([209.85.216.175]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1fg9lg-0008Mf-Sv for pgsql-hackers@postgresql.org; Thu, 19 Jul 2018 14:19:00 +0000 Received: by mail-qt0-f175.google.com with SMTP id y5-v6so7292762qti.12 for ; Thu, 19 Jul 2018 07:18:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:to:cc:references:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=p9rQHI1GQVR/KEPGCzMyNzLZfdita3MsmdpRdhaXI88=; b=jMkCk4vFz+nF7mbGl9Ul4dsLoWzOOsKb7NYaeADpT6o/j9FDEqQ74Z1hxmFOUy4/F0 4WRVr/yEr+6M2vOgpWKHupwfS0b9BWHTTez9xNsli1WOOidaESCVQV7f7nEBY2sYJNCo iPqdZF70R6t7kugjlxT0WG8SyQ/xkAbaw7WQxKW5ekyqVyzKtVfe8rIgrTVDlMp9lZKQ 09cnBoGILdQ1aFOrrlZC7MjvEiVDLNee+CCQo7dMszEWbVaJUDp8ElRUD3JaNSUY9vqr k/kLBNxb3372fcUTdhKz6d3r0bbLPsO7iT4LMSPVKAzzid1Tzyna3K+FDcSHVnhgtuua cfTg== X-Gm-Message-State: AOUpUlFXaZk1A6Le9oHvmgewjW9DU2CKUT3V0yoizdqDr9kJrrt+iri+ 06B1k/V6DQm9DHjUpeXbHn7Xkk5jcxA= X-Google-Smtp-Source: AAOMgpeiG9tN1+BBQQg8HPjXZ9qv0H1YIppHaP9xJ2DNHLxf2EqejxW8mECFeIBfuomXQenG2lXJOw== X-Received: by 2002:ac8:367:: with SMTP id w39-v6mr10091904qtg.334.1532009934057; Thu, 19 Jul 2018 07:18:54 -0700 (PDT) Received: from localhost.localdomain (c-24-61-8-151.hsd1.ma.comcast.net. [24.61.8.151]) by smtp.gmail.com with ESMTPSA id e20-v6sm7965349qkh.32.2018.07.19.07.18.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jul 2018 07:18:52 -0700 (PDT) Reply-To: jesper.pedersen@redhat.com Subject: Re: partition tree inspection functions To: Amit Langote Cc: Michael Paquier , Jeevan Ladhe , Pg Hackers 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> From: Jesper Pedersen Organization: Red Hat Message-ID: <38183355-ea7c-9443-0c38-6124fcf5f38b@redhat.com> Date: Thu, 19 Jul 2018 10:18:51 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi Amit, On 07/19/2018 04:39 AM, Amit Langote wrote: >> I think pg_partition_tree_tables should have an option to exclude the >> table that is being queried from the result (bool include_self). > > Doesn't sound too bad, so added include_self. > 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. >> 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. Thanks for considering. Best regards, Jesper