MIME-Version: 1.0
References: <CA+TgmoZv8DvmeQHQAX+rkn68id2N+DoUhFZB36d-_w1tyAeqeA@mail.gmail.com>
 <CAM-w4HNLRO8QJvF3x13wjjdkJHobORxaKrcuyF1cKaTiXuvDbA@mail.gmail.com>
 <CALtqXTcZE6YW=m9ZmNU6sRJ+RTC15NFc__foP1S2KaWvGOf6JA@mail.gmail.com>
 <DBBD7E90-677A-4BF3-A5DD-B1A5D12F800C@yesql.se> <A141D263-CA95-4873-BCC7-2573C908DAED@yesql.se>
 <c54a600c-31f8-4db6-b049-e643ae812d38@tantorlabs.com> <CAECtzeVpocPwcQ0ccrXsmcvH_8YkJBdUfsJCzb8NKrEodmCg_w@mail.gmail.com>
 <55695d15-c738-4401-8883-58bc855c9b03@tantorlabs.com> <58bb3a5b-c92a-408c-b02a-f47aedc1c0e2@tantorlabs.com>
 <CAFY6G8f6Sdu9cvfF2NYWWZMHD0ecTCPuNT7VktPH5NwxY7hcog@mail.gmail.com>
 <70bc1af0-6910-4f71-84ba-fa02095fe9ba@tantorlabs.com> <CAFY6G8dgp494Xi2+VUUyM2CvuSQ+3nnzWi44gURWbCHjEWW89g@mail.gmail.com>
 <fc28108a-8e7e-4f7d-b8f4-0bcc1581650d@tantorlabs.com> <CA+Tgmobgkh5CW=4Xpejw9nR6Onv8SZh0nnr+=HmNAFyyHZb0eg@mail.gmail.com>
 <3212947.1739306803@sss.pgh.pa.us> <eb73d4e1-4235-41b5-90a8-b0196550f62b@gmail.com>
 <a51fc17e-8702-4928-863b-ea3eecf940bf@tantorlabs.com>
In-Reply-To: <a51fc17e-8702-4928-863b-ea3eecf940bf@tantorlabs.com>
From: Robert Haas <robertmhaas@gmail.com>
Date: Wed, 12 Feb 2025 13:19:11 -0500
Message-ID: <CA+TgmobT9gPQLtw143oGnKVNtaOrTDOy+ZbLfe18MVZ9POjaWg@mail.gmail.com>
Subject: Re: explain analyze rows=%.0f
To: Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>
Cc: Andrei Lepikhov <lepihov@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, 
	Matheus Alcantara <matheusssilv97@gmail.com>, Guillaume Lelarge <guillaume@lelarge.info>, 
	Daniel Gustafsson <daniel@yesql.se>, Ibrar Ahmed <ibrar.ahmad@gmail.com>, 
	"Gregory Stark (as CFM)" <stark.cfm@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>, 
	Justin Pryzby <pryzby@telsasoft.com>, Peter Geoghegan <pg@bowt.ie>, vignesh C <vignesh21@gmail.com>, 
	"David G. Johnston" <david.g.johnston@gmail.com>, pgsql-hackers@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CA%2BTgmobT9gPQLtw143oGnKVNtaOrTDOy%2BZbLfe18MVZ9POjaWg%40mail.gmail.com>
Precedence: bulk

On Wed, Feb 12, 2025 at 5:10=E2=80=AFAM Ilia Evdokimov
<ilya.evdokimov@tantorlabs.com> wrote:
> I think the idea of keeping two significant digits after the decimal
> point is quite reasonable. The thing is, rows=3D0.000001 or something
> similar can only occur when loops is quite large. If we show the order
> of magnitude in rows, it will be easier for the user to estimate the
> order of total rows. For example, if we see this:
>
> rows=3D0.000056 loops=3D4718040
>
> the user can quickler approximate the order of total rows for analyzing
> the upper levels of the query.

I agree that showing 2 digits after the decimal point in all cases is
not ideal, but I suggest that we take a practical approach. Figuring
out dynamically what number of decimal digits to display in each case
sounds complicated and we may spend a bunch of time arguing about the
details of that and get nothing committed. If we just show 2 digits
after the decimal point, it will not be perfect, but it will be 10^2
times better than what we have now.

If I'm honest, what I actually think we should do is stop dividing
values by nloops before printing them out. Every time I'm looking at a
quantity that has been divided by nloops, the very first thing I do is
try to figure out what the original value was. The whole reason I want
to display at least a couple of decimal digits here is so that I can
do that more accurately, but of course the dream would be not having
to reverse engineer it like that at all. However, I expect fierce
opposition to that idea, and no matter how misguided I may think that
opposition might be, a patch in the tree is worth two in the
CommitFest.

--=20
Robert Haas
EDB: http://www.enterprisedb.com