Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qQrnC-001E8i-VH for pgsql-hackers@arkaria.postgresql.org; Tue, 01 Aug 2023 16:00:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qQrnA-007w3R-K3 for pgsql-hackers@arkaria.postgresql.org; Tue, 01 Aug 2023 16:00:14 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qQrnA-007w3H-B8 for pgsql-hackers@lists.postgresql.org; Tue, 01 Aug 2023 16:00:13 +0000 Received: from mail-pl1-x636.google.com ([2607:f8b0:4864:20::636]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qQrn8-000E36-T1 for pgsql-hackers@postgresql.org; Tue, 01 Aug 2023 16:00:13 +0000 Received: by mail-pl1-x636.google.com with SMTP id d9443c01a7336-1bbff6b2679so18780965ad.1 for ; Tue, 01 Aug 2023 09:00:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690905609; x=1691510409; h=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=gO1zEEYoygFoWM9Ky8ZzHnX50Tm7XPpBoSo6E5Bf3Zc=; b=LzxT8y3s/rMmVBF6L+x8WXf+eL0/qhbSnSN8AYkrbne1g8/3PrWmDXM5Ndnht8Gruv fxedBjfoh539+GOGV8kUO7BMD1j6/avlFGawNYIWggZdk5JCZH8c+eOCZFfRMiJmkU/1 MBb9clxRJBvCwmXaFtbmnyqN64EPLAWbTLG1L3ZVY0nJI6OiIwlb60vhOjKFHtyu/8fF FIadNMT9SDxdcheqaFTbqsRtHQIg1lyCoNO9ysUPavcZZOiZXF03UZrPVDhhTUpJ3YZB HOmOijdL39pp3QXSLteIgdGg26d7i4sO6l/X1JSzp95xpRQjO9f4dkZAp7x6UJv9Qqj9 63ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690905609; x=1691510409; h=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=gO1zEEYoygFoWM9Ky8ZzHnX50Tm7XPpBoSo6E5Bf3Zc=; b=ZvQsZxX3DMGMAzTBtPYTDgNuVqOxU2lQo4FnY8YDlEnOVZHAoQSzFri6KY2G56u7DP VE5goRjb8DArD5kLk6aIDHgSgsE0I95/n8K4qDO4AebZAf/re0CIm4VUQgsstch9Q5tq UjzU+yQqdhcJSsZwgVcdSiRdpen1p3Ph4jTpu6CTl05ZC+DUjnmk5SPUsS1UGnJiHDt1 SXFI2epgmO9C/pjhaMM3vG/XgclK7VY4fqOKf3HztqFcpKxZhCUv5Fain480RLeeoslg 8UXmsn8Hm5D7Iz1lsg8vbtnW5zFiK8yPQKNiYS8EIPUH93OT9PDGGxXCr1TdIHPwGh6r D15A== X-Gm-Message-State: ABy/qLZME8zLGoSTYhz2A1vOTyEGcSFI1tSQwOKalJMwP5DW+HqL5pUr 5b62Gfse5Cs1wrwrnhXwP4g= X-Google-Smtp-Source: APBJJlGgb8U7R0rYpUY0OqJdSk5BMfHD03XgwVS95C7dIuP0mpFW+lc0FK5kW5k6jAh/Z2FltyRLZw== X-Received: by 2002:a17:903:248:b0:1b6:b44d:a5b6 with SMTP id j8-20020a170903024800b001b6b44da5b6mr11922611plh.14.1690905608600; Tue, 01 Aug 2023 09:00:08 -0700 (PDT) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id ji20-20020a170903325400b001ac591b0500sm10677883plb.134.2023.08.01.09.00.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Aug 2023 09:00:08 -0700 (PDT) Date: Tue, 1 Aug 2023 09:00:06 -0700 From: Nathan Bossart To: Daniel Gustafsson Cc: Peter Eisentraut , PostgreSQL Hackers Subject: Re: add timing information to pg_upgrade Message-ID: <20230801160006.GB723589@nathanxps13> References: <20230727235134.GA3658499@nathanxps13> <204e3982-78be-7550-fdb3-063ecd368f1f@eisentraut.org> 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 Tue, Aug 01, 2023 at 09:58:24AM +0200, Daniel Gustafsson wrote: >> On 1 Aug 2023, at 09:45, Peter Eisentraut wrote: >> On 28.07.23 01:51, Nathan Bossart wrote: > >>> This information can be used to better understand where the time is going >>> and to validate future improvements. >> >> But who would use that, other than, you know, you, right now? One of the main purposes of this thread is to gauge interest. I'm hoping there are other developers who are interested in reducing pg_upgrade-related downtime, and it seemed like it'd be nice to have built-in functionality for measuring the step times instead of requiring folks to apply this patch every time. And I think users might also be interested in this information, if for no other reason than to help us pinpoint which steps are taking longer for various workloads. >> I think the pg_upgrade output is already too full with not-really-actionable information (like most of the above "Checking ..." are not really interesting for a regular user). Perhaps. But IMO it's nice to know that it's doing things and making progress, even if you don't understand exactly what it's doing all the time. That being said, I wouldn't be opposed to hiding some of this output behind a --verbose or --debug option or consolidating some of the steps into fewer status messages. > Maybe if made opt-in with a --debug option, or even a compiler option for > enabling only in specialized debugging builds? I'm totally okay with making the timing information an opt-in feature. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com