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 1fn0sU-0006ZW-Vj for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Aug 2018 12:14:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fn0sT-0005Ac-1I for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Aug 2018 12:14:17 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fn0sS-0005AP-N6 for pgsql-hackers@lists.postgresql.org; Tue, 07 Aug 2018 12:14:16 +0000 Received: from mail-qt0-f178.google.com ([209.85.216.178]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1fn0sO-0003br-Mj for pgsql-hackers@postgresql.org; Tue, 07 Aug 2018 12:14:14 +0000 Received: by mail-qt0-f178.google.com with SMTP id n6-v6so17491533qtl.4 for ; Tue, 07 Aug 2018 05:14:11 -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=lJRNgkr2peJfV4TYnrgKocvfvwB8/oZWbekWtU8hFqI=; b=Fq0HuisPJqfCO48RZN8cZgQyBHS18Vt1gA1cBanfKzYUD6LV0cNGAYG8D6ORmomIej 6YAYAIsjeBaA3L9+KZgMSMA95fdLOaIVAwRs49LVwav1IHfRAwA7ucUiAtriNiUTHAIQ hU3QXWMfmx8w5AeGJ6hSM2cCjg0xeKf8+eSfx3C22KQzX1IdkUagDCMIH4a882qZBh5n eoHpk0YoSNawK3Yh14t64mNjhMvvJ43NgiVfiWqn2zpPrdQtQI5yYNLd9GWO9DzlYAcg tCgJGouraP1QPkhrElsG3KhsxOLvD/yKLcwSeIHe03uT0um4pFmlQYg82mzClB4+PQ1L NWiw== X-Gm-Message-State: AOUpUlEm+5+2DfcjxK9ZOYR5GES/VWVX+ysiONWH/tvydd1aizQFMvqQ uUhw63intukA4dXdhEf4vBTI4W/AZAw= X-Google-Smtp-Source: AAOMgpceKkC5bWHbUIJvVPko1Ko3c48cqHQrITHT7CI5cw3rNhHLh3xz981vuSTQ0nFKn2qO3/Vfcw== X-Received: by 2002:ac8:2f31:: with SMTP id j46-v6mr18351517qta.93.1533644050993; Tue, 07 Aug 2018 05:14:10 -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 v192-v6sm837580qkb.0.2018.08.07.05.14.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Aug 2018 05:14:09 -0700 (PDT) Reply-To: jesper.pedersen@redhat.com Subject: Re: partition tree inspection functions To: Amit Langote , Robert Haas 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> <38183355-ea7c-9443-0c38-6124fcf5f38b@redhat.com> <5686970f-b4e8-bbe5-9109-b97763714c19@lab.ntt.co.jp> <3273a7af-3aca-eb86-cedb-f7b28be00831@lab.ntt.co.jp> <28d6f8eb-afda-1bfd-141d-ca489cffb0ee@lab.ntt.co.jp> <7f2e6674-9196-9fe7-1405-368bafd64198@redhat.com> <5e91cf39-4727-903a-779c-7b7b081ac7e9@lab.ntt.co.jp> From: Jesper Pedersen Organization: Red Hat Message-ID: <8d200fc4-dda4-f4ee-4f9c-efdb05a12e59@redhat.com> Date: Tue, 7 Aug 2018 08:14:08 -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: <5e91cf39-4727-903a-779c-7b7b081ac7e9@lab.ntt.co.jp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi, On 08/07/2018 03:32 AM, Amit Langote wrote: > Do we need a pg_partition_level that expects the individual partition OID > to be passed to it or can we do with the information we get from the > revised pg_partition_children? In earlier revisions, > pg_partition_children returned only the partition OIDs, so we needed to > provide pg_partition_* functions for getting the parent, root parent, > level, etc. separately. I mean to ask if is there a need for having these > functions separately if the revised pg_partition_children already outputs > that information? > I'm thinking of the case where we only have information about a leaf partition, and we need its root partition and the actual level in the partition tree. If we had SELECT pg_partition_root_parent('leafpart'); and SELECT pg_partition_level('leafpart'); -- we don't need the pg_partition_level('leafpart', 'parentpart') function now. We can use pg_partition_children() for the rest. > pg_partition_leaf_children()'s output can be obtained as follows, after > adding isleaf column to pg_partition_children's output: > Yes, this is great. Thanks ! Best regards, Jesper