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 1pEYqy-0006RQ-6E for pgsql-hackers@arkaria.postgresql.org; Sun, 08 Jan 2023 16:49:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pEYqv-000867-Kw for pgsql-hackers@arkaria.postgresql.org; Sun, 08 Jan 2023 16:48:57 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pEYqv-00085x-65 for pgsql-hackers@lists.postgresql.org; Sun, 08 Jan 2023 16:48:57 +0000 Received: from mail-il1-x12a.google.com ([2607:f8b0:4864:20::12a]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pEYqr-0007Mq-7Z for pgsql-hackers@lists.postgresql.org; Sun, 08 Jan 2023 16:48:56 +0000 Received: by mail-il1-x12a.google.com with SMTP id y2so3772195ily.5 for ; Sun, 08 Jan 2023 08:48:52 -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-disposition:mime-version:references :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=2p5Qwy2LUX4iOLbQ82w7KMJpKkg/5+W6nJ5C4hhCCeE=; b=2AyFEe36kZOZsQzjl35sFcRo3IqQ0fVIfLiVr0SprhRIW/Vz3i9pkfmzPxDFMPBfxK Xnmtm5CZ+Q7Nvk2nlb7Jrp42IrIfjYzniao10bHfWqzWsGN2R0NetR9PRXyxz5XVBZ7X aAkznFaC67qyIkY6G+W1h/MZ7sD/Fy+PrDjQu3AKq+ycMIDh5+cjNEa17umHBycLVUhX p6vn0Y7vI/ajTuYR9F/uk/fstgrRuFSpUlBe/QVU7WQMQgJJ7HzUx88afwT2zZsWwIoR J1oSNFIpmj9yKyy1F4BUVj87gF3Mfdx+KRfhoRLZMZM/fAebhdHNfbKf6Kvtz9aOYk+x EiyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=user-agent:in-reply-to: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=2p5Qwy2LUX4iOLbQ82w7KMJpKkg/5+W6nJ5C4hhCCeE=; b=MhbpahXftg3HDuO27bUF/3kSUN5YAX3tECC+iuP8I3PgHpJW0oanzG3O3XEFXqYB/I AUVBljPdLs5nwJFmdUBSJFhZLdUhdVHzGP4UE0ZOiRWrfk60viBMXVTJXOPLN2vVD7jW S/8jcIjTqMNAa9iVZyZa17iENrEM/pclw2izTD2DWm/xGXTR3tpn8LIA2QIQk1LQIbu+ ITU/28Xl209aDSBkbEzUuS+gK2aCdrtZD5/w+g+5inj2mV56g+Y3XKgoyI0yaCejsawZ 4L1f+uKF4Lu/4Ztd2Dl6p3BI691L05M+Oc2vMEpvUmgAb6gGFjb+mc4xWuwRHnGwrppf tQyg== X-Gm-Message-State: AFqh2kp7vNKvKjVsIPSwIzbRqm2Ny5k7hRXCEVlrvGaXNwZ9DjsLUxK7 aDAW38HKvCXbEAUwreoDBNVeJQ== X-Google-Smtp-Source: AMrXdXu923mUA/ATAnmX1vJDVWhWq7Ye6u13hguR12FaZCrfyXBT533VCoFB5p1REC4E0rWwrTbvxA== X-Received: by 2002:a05:6e02:20eb:b0:30d:8785:1e6d with SMTP id q11-20020a056e0220eb00b0030d87851e6dmr9952755ilv.27.1673196531249; Sun, 08 Jan 2023 08:48:51 -0800 (PST) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id n30-20020a02a19e000000b0039de238deb5sm2061811jah.175.2023.01.08.08.48.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 Jan 2023 08:48:50 -0800 (PST) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 6B76A800C2F; Sun, 8 Jan 2023 10:48:49 -0600 (CST) Date: Sun, 8 Jan 2023 10:48:49 -0600 From: Justin Pryzby To: Ilya Gladyshev Cc: pgsql-hackers@lists.postgresql.org Subject: Re: Progress report of CREATE INDEX for nested partitioned tables Message-ID: <20230108164849.GA21731@telsasoft.com> References: <039564d234fc3d014c555a7ee98be69a9e724836.camel@gmail.com> <20221217143002.GR1153@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221217143002.GR1153@telsasoft.com> 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 Sat, Dec 17, 2022 at 08:30:02AM -0600, Justin Pryzby wrote: > We have the common problem of too many patches. > > https://www.postgresql.org/message-id/a15f904a70924ffa4ca25c3c744cff31e0e6e143.camel%40gmail.com > This changes the progress reporting to show indirect children as > "total", and adds a global variable to track recursion into > DefineIndex(), allowing it to be incremented without the value being > lost to the caller. > > https://www.postgresql.org/message-id/20221211063334.GB27893%40telsasoft.com > This also counts indirect children, but only increments the progress > reporting in the parent. This has the disadvantage that when > intermediate partitions are in use, the done_partitions counter will > "jump" from (say) 20 to 30 without ever hitting 21-29. > > https://www.postgresql.org/message-id/20221213044331.GJ27893%40telsasoft.com > This has two alternate patches: > - One patch changes to only update progress reporting of *direct* > children. This is minimal, but discourages any future plan to track > progress involving intermediate partitions with finer granularity. > - A alternative patch adds IndexStmt.nparts_done, and allows reporting > fine-grained progress involving intermediate partitions. > > https://www.postgresql.org/message-id/flat/039564d234fc3d014c555a7ee98be69a9e724836.camel@gmail.com > This also reports progress of intermediate children. The first patch > does it by adding an argument to DefineIndex() (which isn't okay to > backpatch). And an alternate patch does it by adding to IndexStmt. > > @committers: Is it okay to add nparts_done to IndexStmt ? Any hint about this ? This should be resolved before the "CIC on partitioned tables" patch, which I think is otherwise done.