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 1flZJM-0000BY-QG for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Aug 2018 12:36:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1flZJK-00061X-Jn for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Aug 2018 12:36:02 +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 1flZJK-00061Q-8j for pgsql-hackers@lists.postgresql.org; Fri, 03 Aug 2018 12:36:02 +0000 Received: from mail-qt0-f174.google.com ([209.85.216.174]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1flZJH-0006fT-2K for pgsql-hackers@postgresql.org; Fri, 03 Aug 2018 12:36:00 +0000 Received: by mail-qt0-f174.google.com with SMTP id b15-v6so5859328qtp.11 for ; Fri, 03 Aug 2018 05:35:58 -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=3myKXjLnTvZC0sg6U3iE+HQnZUdNGe6BZP1u4GJv4aM=; b=Y+NZWDsp1p1EYuQEgMsAqhe0KBbiMey3XgpX8nqvS0g+Nbz7J1D6VAwET8a1/1jtXc qAsmgvAYgCAHa4kmt8lXG5RI4F+rBTacFSm8rqZchUn+PH27An7+EMCJ7RGSQf3jlz2p XQkqgAvD+TYAjdjK3S4RU3qPKwHjl1zvDLnj27hRz3COQkbRpeXZYR84g9i0+0Hv4vWA wly3Afp3i6a9CHsol1VzoIjqdxe1azKzcMFCseHsPxFQMt+VFSk43XOFt2J403jPCt32 MR7N7RKRIqKY474wKOvg3VirVnSKxpsnox5E3sB7rkVzgu7UKHzVuSsXhv6+i2fF53TN KIDg== X-Gm-Message-State: AOUpUlGHtZoOIYl9ZHIy7oDRtcQUuU2mVd6wXtYQJ1OsvcsoN6+BWH+k sZhCoDzTi09elNib4l+WEC3NwlaSOJQCBQ== X-Google-Smtp-Source: AAOMgpcq5gWitFSNTx0ny+7j1zjPQRFhT7Erei1xbHyXw93eE1GsMjcb3eQaV0tTHLSOK7wviw58Xg== X-Received: by 2002:ac8:309a:: with SMTP id v26-v6mr3669319qta.378.1533299757595; Fri, 03 Aug 2018 05:35:57 -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 v187-v6sm2143241qka.73.2018.08.03.05.35.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Aug 2018 05:35:56 -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> From: Jesper Pedersen Organization: Red Hat Message-ID: <7f2e6674-9196-9fe7-1405-368bafd64198@redhat.com> Date: Fri, 3 Aug 2018 08:35:55 -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: <28d6f8eb-afda-1bfd-141d-ca489cffb0ee@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 Amit, On 08/03/2018 04:28 AM, Amit Langote wrote: > That's a good idea, thanks. > > Actually, by the time I sent the last version of the patch or maybe few > versions before that, I too had started thinking if we shouldn't just have > a SETOF RECORD function like you've outlined here, but wasn't sure of the > fields it should have. (relid, parentid, level) seems like a good start, > or maybe that's just what we need. > I think there should be a column that identifies leaf partitions (bool isleaf), otherwise it isn't obvious in complex scenarios. > > Note that the level that's returned for each table is computed wrt the > root table passed to the function and not the actual root partition. > If you are given a leaf partition as input, then you will have to keep executing the query until you find the root, and count those. So, I think it should be either be the level to the root, or there should be another column that lists that (rootlevel). Best regards, Jesper