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 1tWXaV-00HMeI-GL for pgsql-hackers@arkaria.postgresql.org; Sat, 11 Jan 2025 09:15:24 +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 1tWXaU-007ae1-J1 for pgsql-hackers@arkaria.postgresql.org; Sat, 11 Jan 2025 09:15:22 +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 1tWXaU-007adt-4X for pgsql-hackers@lists.postgresql.org; Sat, 11 Jan 2025 09:15:21 +0000 Received: from mail-qk1-x729.google.com ([2607:f8b0:4864:20::729]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tWXaQ-0013DD-0Q for pgsql-hackers@lists.postgresql.org; Sat, 11 Jan 2025 09:15:20 +0000 Received: by mail-qk1-x729.google.com with SMTP id af79cd13be357-7b6e4d38185so264294385a.0 for ; Sat, 11 Jan 2025 01:15:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lelarge-info.20230601.gappssmtp.com; s=20230601; t=1736586917; x=1737191717; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=k7F+a4NqMlZgu5+H5v/Nb+d5ojrZrbwWHIGFmuh0O+Q=; b=KfT/ZGhSUcGS8WkH+GRZp+3Zp0TCO1R624yWd0Ou5uo5e86Unqm9hvP68zJGlZZnvu wn9uzynf1Z+Xc8c1i2BVRE/Odju0NWGDXiLxf/8zBDDP/xWLyRMDKThZLPnCPcMmoYWS 3Z8EQYpWxJ+aiwXXwWMlwLbeoZOoNEQK21Ini1dzc84gqe+H6smqawHcAY6tPipxV2e0 TjdA08wUMQfK53JLfedWERrdgRDlr9R0V0T/pCS8S1ZqTTzNz+7BOrkvW7hx8HcKsg/Y fH/ZhynT7g/pfFyMS9nq8UKxUlnKygp0gbWWngzeu3OlqOSGpf346wDvK8iqYSlbroYK BlqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736586917; x=1737191717; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=k7F+a4NqMlZgu5+H5v/Nb+d5ojrZrbwWHIGFmuh0O+Q=; b=TAGx010Q8tNH7Yz3jHjW021irmwpdLONLTIyiVTMNYhGcOOjVu6y06mXtpSHIvKvoe SN1BxQByVcJ5LZimIx52t5fUDy4tCfRc/9ADVycl2RrcrL6Yxs9YdVSIN83JqY8ND0SG TLnVPXFBei4peoqsCmUotJSJ563sZKoJ8LRucbCHloXtlN9QNa4/bMU4NJlLUGCQ/cb0 k/iBWawIgsZQ1o+26ZfGVI9cymqjNqniORWgzykr9Hthj7DUU4VwlaqkbWkPmB26CLlh RgmGfWBmmq2e+QkPec6K6roUKrSosbHcFaa7kYcFci+bYHUazpGAZJWsMvUVBQz01lNA q6HA== X-Forwarded-Encrypted: i=1; AJvYcCWFLlQx0n9ec5PCQnNu99V5zaujEGQOq3FAcyRxsxfXcsWItstRtbv6o2YB9RnHspVj7mnJR0M6JLjqjBAl@lists.postgresql.org X-Gm-Message-State: AOJu0YzYP74ySXX68hRd7/id/OMPqotaLGnL4SYG/Y/+qKs0Gn8DHQqP CKzI9UY6ryo9QLcC59DJGBpChEVxbzz34UUwpeEpkp6VlinuMSwRZa0Uyeowvwk15KzUA9as8S/ aBsasr7YkWbHhRne3f/K3rk0VV5hkvGLqrOugAA== X-Gm-Gg: ASbGncveWW5iLC0IH/Sluoe4Ub77l2+/fk28grp948qKrOA4/XWGr1RUHio+/LKbWLG 36UiRwwj0xyKjTwxYBbSfe2o4wJJiiy+OLxsrfo374DyOStTDIOQZPIzNyLg6zVkItdXD6GOE X-Google-Smtp-Source: AGHT+IH9WCNC1m1oqtmB+XuLFe+4v3R22fL2qHAlhStzK1BYu4o236KPxHXoqxAQxwx5Ets0P62C/6RYFenAMtNMgn4= X-Received: by 2002:a05:620a:3907:b0:7b7:68c:cde5 with SMTP id af79cd13be357-7bcd96e582fmr2372663385a.1.1736586917138; Sat, 11 Jan 2025 01:15:17 -0800 (PST) MIME-Version: 1.0 References: <20220707222015.GD13040@telsasoft.com> <2954811.1667711530@sss.pgh.pa.us> In-Reply-To: From: Guillaume Lelarge Date: Sat, 11 Jan 2025 10:15:06 +0100 X-Gm-Features: AbW1kvaYY2uNJSQc0JvjSLH3okSe8wcbESBdBQaowQFM8E2DG7SXX4S9i-XcdYg Message-ID: Subject: Re: explain analyze rows=%.0f To: Ilia Evdokimov Cc: Daniel Gustafsson , Ibrar Ahmed , "Gregory Stark (as CFM)" , Tom Lane , Robert Haas , Amit Kapila , Justin Pryzby , Peter Geoghegan , vignesh C , "David G. Johnston" , pgsql-hackers@lists.postgresql.org Content-Type: multipart/alternative; boundary="0000000000005161ea062b6aa640" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000005161ea062b6aa640 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, Le jeu. 12 d=C3=A9c. 2024 =C3=A0 12:57, Ilia Evdokimov a =C3=A9crit : > > On 01.08.2023 23:29, Daniel Gustafsson wrote: > >> On 3 Jul 2023, at 18:34, Daniel Gustafsson wrote: > >> > >>> On 8 Jun 2023, at 19:49, Ibrar Ahmed wrote: > >>> On Mon, Mar 20, 2023 at 7:56=E2=80=AFPM Gregory Stark (as CFM) < > stark.cfm@gmail.com > wrote: > >>> This patch was marked Returned with Feedback and then later Waiting o= n > >>> Author. And it hasn't had any updates since January. What is the stat= e > >>> on this feedback? If it's already done we can set the patch to Ready > >>> for Commit and if not do you disagree with the proposed changes? > >>> > >>> If there is a consensus to modify the test cases' output, I am willin= g > to > >>> make the necessary changes and adjust the patch accordingly. However, > >>> if there is a preference to keep the output of certain test cases > unchanged, > >>> I can rebase and modify the patch accordingly to accommodate those > preferences. > >> As there hasn't been any other comments I suggest updating your patch = to > >> address Tom's comments to see if we can make progress here. > > Since there hasn't been any updates here, and the thread has been > stalled, I'm > > marking this returned with feedback. Please feel free to resubmit a > version of > > the patch addressing comments to a future CF. > > > > -- > > Daniel Gustafsson > > > > > > > > Hi everybody, > > When the total number of returned tuples is less than the number of > loops currently shows 'rows =3D 0'. This can mislead users into thinking > that no rows were returned at all, even though some might have appeared > occasionally. For example, if there is 1 tuple over 100 loops, the > average is 0.01 rows per loop, but as displayed it simply looks like zero= . > > To clarify this situation, it has been suggested that display rows with > two decimal places in scenarios where 'loops > 1 && ntuples < loops'. In > other words, show something like 'rows =3D 0.01' instead of 'rows=3D0'. T= his > minor change would make it evident that rows did occur, just very > infrequently. > > For all other cases, the current formatting would remain the same. This > approach aims to provide a more nuanced understanding of query execution > behavior without introducing unnecessary complexity or false precision. > > I would appreciate any thoughts or feedback on this proposal. > > Thanks for your patch, this looks like a very interesting feature that I'd like to see in a future release. It did a quick run: patch OK, make OK, make install OK, but make check fails quite a lot on partition_prune.sql. I guess it would need some work on partition_prune.sql tests and perhaps also on the docs. Thanks again. --=20 Guillaume. --0000000000005161ea062b6aa640 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

Le=C2=A0j= eu. 12 d=C3=A9c. 2024 =C3=A0=C2=A012:57, Ilia Evdokimov <ilya.evdokimov@tantorlabs.com> a = =C3=A9crit=C2=A0:
daniel@yesql.se> wrote:
>>
>>> On 8 Jun 2023, at 19:49, Ibrar Ahmed <ibrar.ahmad@gmail.com> wrote:<= br> >>> On Mon, Mar 20, 2023 at 7:56=E2=80=AFPM Gregory Stark (as CFM)= <stark.cfm@gma= il.com <mailto:stark.cfm@gmail.com>> wrote:
>>> This patch was marked Returned with Feedback and then later Wa= iting on
>>> Author. And it hasn't had any updates since January. What = is the state
>>> on this feedback? If it's already done we can set the patc= h to Ready
>>> for Commit and if not do you disagree with the proposed change= s?
>>>
>>> If there is a consensus to modify the test cases' output, = I am willing to
>>> make the necessary changes and adjust the patch accordingly. H= owever,
>>> if there is a preference to keep the output of certain test ca= ses unchanged,
>>> I can rebase and modify the patch accordingly to accommodate t= hose preferences.
>> As there hasn't been any other comments I suggest updating you= r patch to
>> address Tom's comments to see if we can make progress here. > Since there hasn't been any updates here, and the thread has been = stalled, I'm
> marking this returned with feedback.=C2=A0 Please feel free to resubmi= t a version of
> the patch addressing comments to a future CF.
>
> --
> Daniel Gustafsson
>
>
>

Hi everybody,

When the total number of returned tuples is less than the number of
loops currently shows 'rows =3D 0'. This can mislead users into thi= nking
that no rows were returned at all, even though some might have appeared occasionally. For example, if there is 1 tuple over 100 loops, the
average is 0.01 rows per loop, but as displayed it simply looks like zero.<= br>
To clarify this situation, it has been suggested that display rows with two decimal places in scenarios where 'loops > 1 && ntuples = < loops'. In
other words, show something like 'rows =3D 0.01' instead of 'ro= ws=3D0'. This
minor change would make it evident that rows did occur, just very
infrequently.

For all other cases, the current formatting would remain the same. This approach aims to provide a more nuanced understanding of query execution behavior without introducing unnecessary complexity or false precision.

I would appreciate any thoughts or feedback on this proposal.


Thanks for your patch, this looks like= a very interesting feature that I'd like to see in a future release.

It did a quick run: patch OK, make OK, make install= OK, but make check fails quite a lot on partition_prune.sql.
I guess it would need some work on partition_prune.sql tests an= d perhaps also on the docs.

Thanks again.


--
=
Guillaume.
--0000000000005161ea062b6aa640--