Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pNFQf-00089T-0X for pgsql-hackers@arkaria.postgresql.org; Wed, 01 Feb 2023 15:53:45 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pNFQd-0004r7-5R for pgsql-hackers@arkaria.postgresql.org; Wed, 01 Feb 2023 15:53:43 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pNFQc-0004oS-OD for pgsql-hackers@lists.postgresql.org; Wed, 01 Feb 2023 15:53:42 +0000 Received: from mail-il1-x12b.google.com ([2607:f8b0:4864:20::12b]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pNFQZ-0004K0-A4 for pgsql-hackers@lists.postgresql.org; Wed, 01 Feb 2023 15:53:41 +0000 Received: by mail-il1-x12b.google.com with SMTP id i6so4199468ilq.8 for ; Wed, 01 Feb 2023 07:53:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20210112.gappssmtp.com; s=20210112; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=EVUn88bLIX7rJX929MLvLFnTbZoinEZIkbkIFtV9cFA=; b=qYka2OyslbABPn1JrVvdUfpnF+KBjLAmlbvpyYCUMa22BFF4Y7pd+3Ecfd7V/FGVuu d6mx70UXRu8+PRQQ8wlOyB3fvMXD674hGF2RwMz1U/KY+pO9/xw00kVPAb0RpmXjvr4f T4URdNlRaOIiq2U1bJj3RaBJuoy/nHkpKtCZSQk37b+N9BRS8DS6Yct8ah76dHic/acu bktb/lcCyUArgJvGRf0UxVPJB9JF/j/ZaAgnE34+Tb2kh8RSU981o8Ks3QN/DabW+lhw qnRCIICSUFJ1s8/cgFw4Zh9Vdn5LFp3wE2QEduIrM7PtouP0skQ2Bdt64FMf3soWz6g/ yL+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=EVUn88bLIX7rJX929MLvLFnTbZoinEZIkbkIFtV9cFA=; b=iK3ZSixU1OB31dYOXhEESl8A4dvMuPIMnXhkwE0R/kK++tiHb+oBKWf/zrQVa2ydE9 eoDUO8otW5H5q+WxAQWIwpNZSLnSEnmJqG+VkRk3kiKis1Um7DD8Rz7F22a9lqhuUxBY Xh5ELFMNbJel14PNZJhUIC3vAH9F6tuv/1bivknvuonbNOE/fb0cU/63OxxTlaFgyX9y 0ioJvoSbFkU0YofAnKZXtuHwDmweyVMB5nNNiPuhv9szHAH5jb2iFZxK85KAzOuYRYH+ Itm9P7g48XmbAK1BHaK1R8rNNVuOgaG0nmjhvPjF2diD+kVnzDl9eV3bnsjhousn8ODy 1TlA== X-Gm-Message-State: AO0yUKWzab8JiIgL3AMGh7yHJsrypeAcTwFXjZkxrqGpQmhaGfBWsbzm 5y0pV7Y/Ww3u2RLvgWzVDzsO/A== X-Google-Smtp-Source: AK7set9A0KbMzIQpZ6z0tK9ax7b65BuM0cKfCbF6HzB3OSlOoBCBELTgNUak26HwRSmCVERbYhUb2A== X-Received: by 2002:a05:6e02:20c6:b0:311:d01:6018 with SMTP id 6-20020a056e0220c600b003110d016018mr2723308ilq.8.1675266818562; Wed, 01 Feb 2023 07:53:38 -0800 (PST) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id a7-20020a029987000000b003a2b9bcec56sm6878573jal.67.2023.02.01.07.53.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Feb 2023 07:53:38 -0800 (PST) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 128CC800778; Wed, 1 Feb 2023 09:53:36 -0600 (CST) Date: Wed, 1 Feb 2023 09:53:36 -0600 From: Justin Pryzby To: Matthias van de Meent Cc: Ilya Gladyshev , Alvaro Herrera , Tomas Vondra , pgsql-hackers@lists.postgresql.org Subject: Re: Progress report of CREATE INDEX for nested partitioned tables Message-ID: <20230201155336.GU22427@telsasoft.com> References: <20230201120126.wrkiohouhdohzac5@alvherre.pgsql> <5073D187-4200-4A2D-BAC0-91C657E3C22E@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Feb 01, 2023 at 04:21:35PM +0100, Matthias van de Meent wrote: > On Wed, 1 Feb 2023 at 15:21, Ilya Gladyshev wrote: > > > 1 февр. 2023 г., в 16:01, Alvaro Herrera написал(а): > > > Hmm, count_leaf_partitions has to scan pg_inherits and do a syscache > > > lookup for every single element therein ... this sounds slow. > > > > > > In one of the callsites, we already have the partition descriptor > > > available. We could just scan partdesc->is_leaf[] and add one for each > > > 'true' value we see there. > > > > The problem is that partdesc contains only direct children of the table and we need all the children down the inheritance tree to count the total number of leaf partitions in the first callsite. > > > > > In the other callsite, we had the table open just a few lines before the > > > place you call count_leaf_partitions. Maybe we can rejigger things by > > > examining its state before closing it: if relkind is not partitioned we > > > know leaf_partitions=0, and only if partitioned we count leaf partitions. > > > I think that would save some work. I also wonder if it's worth writing > > > a bespoke function for counting leaf partitions rather than relying on > > > find_all_inheritors. > > > > Sure, added this condition to avoid the extra work here. > > > > > When creating an index on a partitioned table, this column is set to > > - the total number of partitions on which the index is to be created. > > + the total number of leaf partitions on which the index is to be created or attached. > > I think we should also add a note about the (now) non-constant nature > of the value, something along the lines of "This value is updated as > we're processing and discovering partitioned tables in the partition > hierarchy". But the TOTAL is constant, right ? Updating the total when being called recursively is the problem these patches fix. -- Justin