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 1nNgeF-0000w5-26 for pgsql-hackers@arkaria.postgresql.org; Fri, 25 Feb 2022 19:53:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nNgeD-0007Fi-UO for pgsql-hackers@arkaria.postgresql.org; Fri, 25 Feb 2022 19:53:01 +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 1nNgeD-0007FZ-KH for pgsql-hackers@lists.postgresql.org; Fri, 25 Feb 2022 19:53:01 +0000 Received: from mail-pj1-x102a.google.com ([2607:f8b0:4864:20::102a]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nNgeB-0007nF-0F for pgsql-hackers@postgresql.org; Fri, 25 Feb 2022 19:53:01 +0000 Received: by mail-pj1-x102a.google.com with SMTP id g7-20020a17090a708700b001bb78857ccdso9351949pjk.1 for ; Fri, 25 Feb 2022 11:52:58 -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=27ylnNlV8/Hpl7dNZnH9trd/vpoaxNipVtoslDPYGTM=; b=bn7LzvS9+GHP/3f0X27mcDrlmb7yykcjBYatfKkVE69uZLfjnk+53NtUD85oi9+hrH MOjqjyzsEuyCJOJqJmsfw2XQ/dmsTRxZjQFxhMcfpILHySrbGTwHD/F3kJv8tI3Y8Xum HJResrAyjvrl0k2/5mG2bPHowvnQPfE5a3HsaKFubeFkAsrrcOR1+JX/OX9VVUEI+iSc 5YUcV0qgX+focBkD238bVBH5Fkvad+6tugTjoo1NZ6bGzt21bFLmTc+pNVK8DewDZRkl TMeIgDGVi+e1LAOW9vWSHcdD23JquErff0vRaf3zsinKrE/+nmKUbd/yeHPRI2OeGkeB FlgQ== 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=27ylnNlV8/Hpl7dNZnH9trd/vpoaxNipVtoslDPYGTM=; b=TIzIv/tnTDAWW5nysH85dljr+pOEe4SyrFMknIPhDm8jC3L1Ctre2XLRc9Y6Ns8G/i RGCGKUATMb6sqtWBlSedKQn3BnQooXoURuN2LW+uxE0TW6tcGcJDDF98MrolgJ/4IYOu TRHu9RP4H2nry6O35lHNEWtCa2X1pppFco+PLWsSNVQPQzKogtLgTZntdFcHGLuzYstb Rr7cSsaQ/6ncYWjeB/hU8TuPN2t3dUjnKCfp/LIEMnnHefJ/xQoP8LTPw7+cHDnu+D3E hO5od+T7f5eBt8+BjTo5x0rQoFwEjn+dGWOEwCoTMhST/l5185a1b2U/ggFS9it7WWHA PqOQ== X-Gm-Message-State: AOAM530fjEN+1gObrR+efMVP1rMqGoAT7Xfbz2yAT1uaIQm8mmP1QKad Che3lSoMs47e7/0dZTFtwmM= X-Google-Smtp-Source: ABdhPJxfWTHlFsZ683KIJLu2Vbs4hHJQXzgDXydr0shPY3t9AswU7LVzj4/Fch3Qdsokbw1ikTxW7g== X-Received: by 2002:a17:902:bd4a:b0:149:936b:8306 with SMTP id b10-20020a170902bd4a00b00149936b8306mr9468349plx.134.1645818776009; Fri, 25 Feb 2022 11:52:56 -0800 (PST) Received: from nathanxps13 ([50.54.155.70]) by smtp.gmail.com with ESMTPSA id g1-20020a056a000b8100b004f111c21535sm4383778pfj.80.2022.02.25.11.52.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Feb 2022 11:52:55 -0800 (PST) Date: Fri, 25 Feb 2022 11:52:53 -0800 From: Nathan Bossart To: Peter Geoghegan Cc: "Imseih (AWS), Sami" , "Bossart, Nathan" , Masahiko Sawada , Justin Pryzby , "pgsql-hackers@postgresql.org" Subject: Re: Add index scan progress to pg_stat_progress_vacuum Message-ID: <20220225195253.GA663211@nathanxps13> References: <6753CC4A-D1D8-477D-9B82-CFE12169DFF5@amazon.com> <7A4B3BA8-0768-4463-9B25-25DBECF56B25@amazon.com> <96387867-CBAF-4CCF-861E-2F4ACBCBBD68@amazon.com> <441BA1FF-23AA-4CEE-9976-7FB693C30D00@amazon.com> <1E7CB510-FB91-4DDB-93E1-A19C05F299F3@amazon.com> <20220221190910.GA3740885@nathanxps13> <28F7536A-3E62-4A6B-9705-A2377A2D03AE@amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Feb 23, 2022 at 10:41:36AM -0800, Peter Geoghegan wrote: > On Wed, Feb 23, 2022 at 10:02 AM Imseih (AWS), Sami wrote: >> If the failsafe kicks in midway through a vacuum, the number indexes_total will not be reset to 0. If INDEX_CLEANUP is turned off, then the value will be 0 at the start of the vacuum. > > The way that this works with num_index_scans is that we "round up" > when there has been non-zero work in lazy_vacuum_all_indexes(), but > not if the precheck in lazy_vacuum_all_indexes() fails. That seems > like a good model to generalize from here. Note that this makes > INDEX_CLEANUP=off affect num_index_scans in much the same way as a > VACUUM where the failsafe kicks in very early, during the initial heap > pass. That is, if the failsafe kicks in before we reach lazy_vacuum() > for the first time (which is not unlikely), or even in the > lazy_vacuum_all_indexes() precheck, then num_index_scans will remain > at 0, just like INDEX_CLEANUP=off. > > The actual failsafe WARNING shows num_index_scans, possibly before it > gets incremented one last time (by "rounding up"). So it's reasonably > clear how this all works from that context (assuming that the > autovacuum logging stuff, which reports num_index_scans, outputs a > report for a table where the failsafe kicked in). I am confused. If failsafe kicks in during the middle of a vacuum, I (perhaps naively) would expect indexes_total and indexes_processed to go to zero, and I'd expect to no longer see the "vacuuming indexes" and "cleaning up indexes" phases. Otherwise, how would I know that we are now skipping indexes? Of course, you won't have any historical context about the index work done before failsafe kicked in, but IMO it is misleading to still include it in the progress view. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com