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 1oEqDJ-00049F-VR for pgsql-hackers@arkaria.postgresql.org; Fri, 22 Jul 2022 10:48:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oEqCK-000310-49 for pgsql-hackers@arkaria.postgresql.org; Fri, 22 Jul 2022 10:47:56 +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 1oEqCJ-00030r-PA for pgsql-hackers@lists.postgresql.org; Fri, 22 Jul 2022 10:47:55 +0000 Received: from mail-yw1-x112d.google.com ([2607:f8b0:4864:20::112d]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oEqCH-0002jd-FI for pgsql-hackers@postgresql.org; Fri, 22 Jul 2022 10:47:54 +0000 Received: by mail-yw1-x112d.google.com with SMTP id 00721157ae682-31e7055a61dso43130107b3.11 for ; Fri, 22 Jul 2022 03:47:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HRv26exhQNPrX46YO8bZUnxZ2V6J74foqBZSM/ia+GU=; b=HDF8DLSbP6hcKa12PDaNWe5Igs8Guh7vxEyn5VSrszAClR89OOYBWR3g5Jsri/gnEw na6MSoKrL4gD1tGRQerChAXP2PjZij6wg6Mk0yBqrFe8XakabWi/WJ+1rb7fnXWqlS4Q GhXCjbh/N5hMrL3fi17PoKKX3rXlLywxYAz1wUyqx0gmMQ4lJkLtl5aVKP9ohXPB6PGE 17yshpjgjXqOUEDlavtD/+yB9SUfVxsiKHMjWNO/MvRvhfTJFmPWB0itVUZuOvUYfP0f E9RIbOLUma0SJhDTRZVb9130nP0eGCrgZGyOaET4JsFt3e8pokReEZFtxRByYoFjqGIo /svQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HRv26exhQNPrX46YO8bZUnxZ2V6J74foqBZSM/ia+GU=; b=wMmdlpHKJj4f+Yhn2U+6ei4Q9p0s/eOJcwzQDHiqOoC9Fs3JxZWBtkuJ01vctACOMk sJAac5NeFBUGE/mbCNzYAnb2Xad8D4bG2AinNkZENV+dOTl7t+HpOxYH585nQYX689c2 W65GyBYw74qr825pu15S4EqaFfETbCNp9uTC4by3oohyt2SbFjaFM51rWxmen2oXsN8E OSCP714fcFRgn6RR27/4BntIwq3Ydm1da43yEfvae255pJjApzgsT0yRdbxJvAZetAiP 90ilK+jmjofZriKBuWoPZxthE5gt5MXrBSDfJT4FaepjyKpSPDoFyeZCnmE/ZWNmi1ti FYkA== X-Gm-Message-State: AJIora+97ZjfeZnvpxBB4Eizkjz9zjsOE0DCTNGdNjJFtUBVx5k9fqVt ZZg2wuGvjAS0oEgrEuXKaJNcyNtv0Zc9ZBBVwwE= X-Google-Smtp-Source: AGRyM1s2C5RJPyMLZi37l1rD+XJbX05u0+X4dndBv53MPIYh91gZFCrApK1YeytBwJbumyMrVHo3zZ8oQvXIoRzFCvQ= X-Received: by 2002:a81:1c0e:0:b0:31c:c207:c5ab with SMTP id c14-20020a811c0e000000b0031cc207c5abmr2405103ywc.182.1658486872619; Fri, 22 Jul 2022 03:47:52 -0700 (PDT) MIME-Version: 1.0 References: <20220707222015.GD13040@telsasoft.com> In-Reply-To: <20220707222015.GD13040@telsasoft.com> From: Amit Kapila Date: Fri, 22 Jul 2022 16:17:41 +0530 Message-ID: Subject: Re: explain analyze rows=%.0f To: Justin Pryzby Cc: Peter Geoghegan , Robert Haas , Greg Stark , vignesh C , Ibrar Ahmed , "David G. Johnston" , pgsql-hackers , Simon Riggs , Ron Mayer , Euler Taveira de Oliveira , Tom Lane Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, Jul 8, 2022 at 3:50 AM Justin Pryzby wrote: > > 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. > I feel the discussion has slightly deviated which makes it unclear whether this patch is required or not? -- With Regards, Amit Kapila.