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 1o9ZrE-0004eR-9G for pgsql-hackers@arkaria.postgresql.org; Thu, 07 Jul 2022 22:20:24 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1o9ZrC-0000VX-AI for pgsql-hackers@arkaria.postgresql.org; Thu, 07 Jul 2022 22:20:22 +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 1o9ZrB-0000VN-TQ for pgsql-hackers@lists.postgresql.org; Thu, 07 Jul 2022 22:20:22 +0000 Received: from mail-qt1-x831.google.com ([2607:f8b0:4864:20::831]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1o9Zr8-0000bD-Ff for pgsql-hackers@postgresql.org; Thu, 07 Jul 2022 22:20:20 +0000 Received: by mail-qt1-x831.google.com with SMTP id c13so24875201qtq.10 for ; Thu, 07 Jul 2022 15:20:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :in-reply-to:user-agent; bh=jT6ofUI+QAcJYCg8rppDL18N+7ruueDegHBl4+30/Vo=; b=Rb9aYfZBM22yxXVuzprhB7022JYz4zuquCm/t8Q7k2Eu8+o3dCSiqsd+5Jd3anpSb1 sU1HceB8OYZMCClPf/w/CEEm/u6wWgJdAEI9YWOGhEFUNevqSFASbvf4BLYWhRUJQ5yQ C5qK8XI1/L770RKn7oDIZQ/1jaF/p6opvSGbEybHUjJIICegH79l/1REGUBqQ37ZYuA/ RIpPFScAaqvLHNkDobnDjz2wb+3G96RwEJ3Q59KEz0EfALy/FiMoRP8Yy7qu7t+QKkQ4 AY8OJN/ln6+bNuC27dPkJbHMj/emHUImKKX6av9CpB7b5wYEmmS1pcd8pMgSdiTWFT+s FXpQ== 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:mime-version :content-disposition:in-reply-to:user-agent; bh=jT6ofUI+QAcJYCg8rppDL18N+7ruueDegHBl4+30/Vo=; b=ZV2F6p7YU79ARtWmftkAJ2ML9ZGf7F/RVHS+ute3deV5O8tkMlXUuMNeX9wkuXL6HS yRF+n3k3h9HN846bMngRa2GaleJQPOWu+A1kmcSmE8TFtx+EY8h6hf9bE0eIhfjDrw+S OKkJzina8IAWPCNE/s3OeNBtxYbWXxbl9jyTnahhqG2jt4eLdGgSFv6eFqd9/3G3NHPN f4pNtWlhKgKKBN8UGB/KHsQmw5HLcAZ7YPlPe+ajoDx5yc6axhHjpZ77n6UJ0q8VK+Cn ax+b6+o7FC4QQrKOqFsvS0u4LLwiJjr2roKqeCeo9ppE0SX/JvX6SDxe+Zz6u+fsswpy 5tFQ== X-Gm-Message-State: AJIora/kxgtx9CXRhTHZmGZVffjykM8NB7Fujdk5pwhzVmazMGxj9lx/ KUBk56yaM4Rp/o4pMaEmclgAdw== X-Google-Smtp-Source: AGRyM1tvOqPs+EcvrgJB0lfnqVfrgzOLVnvuipUFciEbtRqAG6Z9ww9OewattR+Cf1oAtjDCbqoEsw== X-Received: by 2002:a05:622a:1ba3:b0:31d:311c:2ce with SMTP id bp35-20020a05622a1ba300b0031d311c02cemr359051qtb.293.1657232417132; Thu, 07 Jul 2022 15:20:17 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id 8-20020ac84e88000000b003117ee89a51sm23841085qtp.70.2022.07.07.15.20.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jul 2022 15:20:16 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id B3D5A8019D7; Thu, 7 Jul 2022 17:20:15 -0500 (CDT) Date: Thu, 7 Jul 2022 17:20:15 -0500 From: Justin Pryzby To: Peter Geoghegan , Robert Haas Cc: Greg Stark , vignesh C , Ibrar Ahmed , "David G. Johnston" , pgsql-hackers@postgresql.org, Simon Riggs , Ron Mayer , Euler Taveira de Oliveira , Tom Lane Subject: Re: explain analyze rows=%.0f Message-ID: <20220707222015.GD13040@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 Thu, Jul 07, 2022 at 04:21:37PM -0400, Robert Haas wrote: > I mean, what I really want here if I'm honest is to not have the > system divide the number of rows by the loop count. And it sort of > sounds like maybe that's what you want, too. You want to know whether > the loop count is actually zero, not whether it's close to zero when > you divide it by some number that might be gigantic. ... > involves a dozen or two different nested loops, and if we didn't > insist on dividing the time by the loop count, it would be MUCH EASIER > to figure out whether the time spent in the Index Scan is a > significant percentage of the total time or not. I think the guiding princible for what to do should be to reduce how much is needed to explain about how to interpret what explain is showing... The docs say this: | In such cases, the loops value reports the total number of executions of the | node, and the actual time and rows values shown are averages per-execution. | This is done to make the numbers comparable with the way that the cost | estimates are shown. Multiply by the loops value to get the total time | actually spent in the node. On Thu, Jul 07, 2022 at 01:45:19PM -0700, Peter Geoghegan wrote: > Plus you could probably > make some kind of concession in the direction of maintaining > compatibility with the current approach if you had to. Right? The minimum would be to show the information in a way that makes it clear that it's "new style" output showing a total and not an average, so that a person who sees it knows how to interpret it (same for the web "explain tools") A concession would be to show the current information *plus* total/raw values. This thread is about how to display the existing values. But note that there's a CF entry for also collecting more values to show things like min/max rows per loop. https://commitfest.postgresql.org/38/2765/ Add extra statistics to explain for Nested Loop -- Justin