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 1nS72r-0003NT-M1 for pgsql-hackers@arkaria.postgresql.org; Thu, 10 Mar 2022 00:52: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 1nS72q-0004tw-HZ for pgsql-hackers@arkaria.postgresql.org; Thu, 10 Mar 2022 00:52:44 +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 1nS72q-0004tm-6e for pgsql-hackers@lists.postgresql.org; Thu, 10 Mar 2022 00:52:44 +0000 Received: from mail-pl1-x636.google.com ([2607:f8b0:4864:20::636]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nS72n-0004N4-IF for pgsql-hackers@postgresql.org; Thu, 10 Mar 2022 00:52:43 +0000 Received: by mail-pl1-x636.google.com with SMTP id w4so3423518ply.13 for ; Wed, 09 Mar 2022 16:52:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=B/HymydB47dAJwgWe14KHB4XN2NkanN3zRZ/fx7mpyo=; b=OZ39Nwgf0GKwndZ1NBFP8eQincTv3kNIgpFcdM7J3SRDLci92Tvk75y0tsrzzQa6kb X7yD27ODbfCuywQ2rlMkel6xQo2WWUPSRSCpwNuDy0ILXndXAXUTEElTYHyLJZSefXr3 unwWgvAllENx4VeC7WS0iXLUijrrDeG4r2LFdATX6SnYcB9Fl1fmqPs/YO16HQp6gk2c UKNDtEIPKIbqHD81WAsP/ZAYGZAzQZm8o7Iyu5Q+PoBPzhXRxpDQ8Wy03b/6dpzWc848 FvXO5yaGAccA3XyopvmGcnlxnIBmhHL9vstyvUIAkrvUMnhFFwwiKKxOSb922h+eoaAu QWlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=B/HymydB47dAJwgWe14KHB4XN2NkanN3zRZ/fx7mpyo=; b=NY4HLEmA74QGHBxSZ7RvWtcRDAi/nluxbipZAT1GwWAEGwor/b7FegUfF/OIsFWxzh S7coe9ThdpTiBTnmhtUDtPxPpalDG1HrdhbaVSMuTcUjDp5MbsIfxtCEPxOwdMpuyswe x8rhpcW5YFWq6DYhx2KePBwdq/r/7AY/tWx9qvL1POuLcJs+ZodH7YQ/DGBdWf6+KI3y CicbenSjRExY9YOGR+J3gGcV3+1++NyzGY6BsgRvjuJ/DknrWrvBmRB9Cl+7PSN3sBXN zO3bkUH3R3ePYJy3KVNbAjHLIXBdpESCzuGOk6DPEKRwmwAm6VZpwUelQMDqwkMHVZrg p9dw== X-Gm-Message-State: AOAM532EBaQaY21iLUJaVF0aQ1OH205KgYrTpLgMEA/fKaAyOU/IP8kp H9OUm4SsHg1W4ans2lfv7+w= X-Google-Smtp-Source: ABdhPJx1mouf56Y7jxyU3X4mA+7mnwMa7DAM14w7/T2LoxCj1RG48emh0R80GSp+vbgGHWwVzEhd1A== X-Received: by 2002:a17:903:32c3:b0:152:c1b:e840 with SMTP id i3-20020a17090332c300b001520c1be840mr2517363plr.40.1646873559203; Wed, 09 Mar 2022 16:52:39 -0800 (PST) Received: from nathanxps13 ([50.54.155.70]) by smtp.gmail.com with ESMTPSA id j9-20020a056a00234900b004f6feec0d6csm4236137pfj.2.2022.03.09.16.52.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Mar 2022 16:52:38 -0800 (PST) Date: Wed, 9 Mar 2022 16:52:37 -0800 From: Nathan Bossart To: "Imseih (AWS), Sami" Cc: Masahiko Sawada , Peter Geoghegan , "Bossart, Nathan" , Justin Pryzby , "pgsql-hackers@postgresql.org" Subject: Re: Add index scan progress to pg_stat_progress_vacuum Message-ID: <20220310005237.GA307769@nathanxps13> References: <28F7536A-3E62-4A6B-9705-A2377A2D03AE@amazon.com> <20220225195253.GA663211@nathanxps13> <99A5CBE8-EC10-42AA-ABB4-4C812EEFD294@amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <99A5CBE8-EC10-42AA-ABB4-4C812EEFD294@amazon.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I took a look at the latest patch set. + + indexes_total bigint + + + The number of indexes to be processed in the + vacuuming indexes + or cleaning up indexes phase. It is set to + 0 when vacuum is not in any of these phases. + Could we avoid resetting it to 0 unless INDEX_CLEANUP was turned off or failsafe kicked in? It might be nice to know how many indexes the vacuum intends to process. I don't feel too strongly about this, so if it would add a lot of complexity, it might be okay as is. BTreeShmemInit(); SyncScanShmemInit(); AsyncShmemInit(); + vacuum_worker_init(); Don't we also need to add the size of the hash table to CalculateShmemSize()? + * A command type can optionally define a callback function + * which will derive Datum values rather than use values + * directly from the backends progress array. I think this can be removed. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com