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 1o9sTp-0004h4-GX for pgsql-hackers@arkaria.postgresql.org; Fri, 08 Jul 2022 18:13:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1o9sTo-000098-BK for pgsql-hackers@arkaria.postgresql.org; Fri, 08 Jul 2022 18:13:28 +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 1o9sTo-00008z-2M for pgsql-hackers@lists.postgresql.org; Fri, 08 Jul 2022 18:13:28 +0000 Received: from mail-vs1-xe2c.google.com ([2607:f8b0:4864:20::e2c]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1o9sTk-0001eD-2D for pgsql-hackers@postgresql.org; Fri, 08 Jul 2022 18:13:27 +0000 Received: by mail-vs1-xe2c.google.com with SMTP id a184so12900005vsa.1 for ; Fri, 08 Jul 2022 11:13:23 -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=coNWkfIboo4fmI+at1IaaBVoFaWK+6YeX2cYmshVD7Y=; b=IySVYOOEo5sxJOdQqukGMFShg1DtVT2Pso5RJiY/Dyft3MV/LD/xmOF686HHTQy80E Ca2+lFVkjL1it2onTMGSof8fU1igEIw6fgWKcf4I5mToU6Ero5DzlfYaLkZULRhpA1XC 3E9N/Qxdzga9uzrieGEIj7r4xuLgNGVfoCBdrffYF99HYLipE/HQHEqCPI0LOYq8IkUB NINPU4hL4IAfP3FJOYmtXDOXEWMPTprjGw/CFDo6P58zxd2KRfteSCSXMkq0PoXK9wZG ATt1jat6Od3+X4P1MXja2GCdo/ykLuhQsMy7PUCo4MP58jrPmLVO3NP1EkkajGG1rzOi B8Yw== 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=coNWkfIboo4fmI+at1IaaBVoFaWK+6YeX2cYmshVD7Y=; b=G7bXoWArFrd7x5IpRe62UT8LugGUT8sbdjpr5ZPFwas4XhEviwhStTHEwgP8LgAKc+ r0/SuqpbrAdM3Wl0M+v9kmWLHRilIAXc3beS9W8WUB5mO4cwSSS2j2j/eKLToy40FmGZ 3+6xGVEZ1e3armnVlwStFzOiC1DdDj2BP77OjHKuUNpbLLBpgbOiOwiEemu7esGuRQB0 2VHoP5P5eDxlvS66f9o4yuxHZbnE8Iuy+cH62rV5CaUbSNF7EGAtAkx4P9mWm/MeFZEr IOpB2uJL4mmD4QCIVCsdEZsZXW7CGKUekdiraOmxX0O4JeMtc92ZQGBhiB9x/GGbPQNQ RfPA== X-Gm-Message-State: AJIora8CRMRF7+eNxw5oQuL6HB35qokcUh+JLuw5yttWGhNoCRLJcoXN /AXaWI3Yjuu0oqMdOfJVdi8fD3iKlONnaj7FfVs= X-Google-Smtp-Source: AGRyM1vMNVCpedwCT6Wc8mcsWm9QLvqLdfzhhaZBUA2nlHsaCAF9x4CgOIP3bAzdhgG4dyiVV0/Nc7a4uZktkk95aUo= X-Received: by 2002:a67:cb11:0:b0:355:84b2:5c58 with SMTP id b17-20020a67cb11000000b0035584b25c58mr2034813vsl.43.1657304003230; Fri, 08 Jul 2022 11:13:23 -0700 (PDT) MIME-Version: 1.0 References: <603c8f070905281830g2e5419c4xad2946d149e21f9d@mail.gmail.com> <4A1F4FD5.7060204@timbira.com> <4A249CE9.6050708@cheapcomplexdevices.com> <1243950060.23910.58.camel@ebony.2ndQuadrant> <11926.1243953507@sss.pgh.pa.us> In-Reply-To: From: Ibrar Ahmed Date: Fri, 8 Jul 2022 23:12:47 +0500 Message-ID: Subject: Re: explain analyze rows=%.0f To: Greg Stark Cc: vignesh C , "David G. Johnston" , "pgsql-hackers@postgresql.org" , Robert Haas , Simon Riggs , Ron Mayer , Euler Taveira de Oliveira , Tom Lane Content-Type: multipart/alternative; boundary="00000000000065bfb205e34f287b" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000065bfb205e34f287b Content-Type: text/plain; charset="UTF-8" On Thu, Jul 7, 2022 at 10:53 PM Greg Stark wrote: > > - -> Parallel Seq Scan on tenk1 (actual rows=1960 > loops=50) > > + -> Parallel Seq Scan on tenk1 (actual rows=1960.00 > > At the not inconsiderable risk of bike-shedding.... > > I'm wondering if printing something like 0.00 will be somewhat > deceptive when the real value is non-zero but less than 1 row per 200 > loops. I wonder if the number of decimal places should be calculated > to produce a minimum of one non-zero digit for non-zero values. > > -- > greg > + -> Parallel Seq Scan on tenk1 (actual rows=1960.00 I have added a new check to remove any ".00" from the output because in the case of parallel queries we are getting that. Secondly, it is disturbing many test case outputs. -- Ibrar Ahmed --00000000000065bfb205e34f287b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jul 7, 2022 at 10:53 PM Greg= Stark <stark@mit.edu> wrote:
> -=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0->=C2=A0 Parallel Seq Scan = on tenk1 (actual rows=3D1960 loops=3D50)
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0->=C2=A0 Pa= rallel Seq Scan on tenk1 (actual rows=3D1960.00

At the not inconsiderable risk of bike-shedding....

I'm wondering if printing something like 0.00 will be somewhat
deceptive when the real value is non-zero but less than 1 row per 200
loops. I wonder if the number of decimal places should be calculated
to produce a minimum of one non-zero digit for non-zero values.

--
greg

+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0->=C2=A0 Parallel Seq Scan on tenk1 (actual rows= =3D1960.00

I have added a new check to remove any = ".00" from the output because in
the case of parallel queries we = are getting that. Secondly, it is disturbing many test case outputs.
<= br>
--
Ibrar Ahmed
--00000000000065bfb205e34f287b--