MIME-Version: 1.0
References: <CA+TgmoZv8DvmeQHQAX+rkn68id2N+DoUhFZB36d-_w1tyAeqeA@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>
 <CA+TgmobT9gPQLtw143oGnKVNtaOrTDOy+ZbLfe18MVZ9POjaWg@mail.gmail.com>
 <3365160.1739385615@sss.pgh.pa.us> <0e4c813a-18eb-41e2-8edb-89b78d43c82d@gmail.com>
 <CA+TgmoYzawdq40C5cN==LRPBvQChZ7t5XxH6wv+zMxnyM7LjBQ@mail.gmail.com>
 <e434311c-0f84-4c2b-a10d-ecb67f1ec19d@tantorlabs.com> <CA+TgmobfeePej0uNfbLy0v6jUrB3D9m1Kh+QQ40_-A9KQjkqUw@mail.gmail.com>
 <f428e80d-8607-4a9d-950c-be9600f24904@gmail.com> <01ec86c1-e04b-4cbe-b641-22cae8b87604@tantorlabs.com>
In-Reply-To: <01ec86c1-e04b-4cbe-b641-22cae8b87604@tantorlabs.com>
From: Robert Haas <robertmhaas@gmail.com>
Date: Mon, 17 Feb 2025 09:19:43 -0500
Message-ID: <CA+TgmobVWYnYDj1HZ--iqeKx+n7zTgtYCar+YfZ0V6wiX-t0Mg@mail.gmail.com>
Subject: Re: explain analyze rows=%.0f
To: Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>
Cc: Andrei Lepikhov <lepihov@gmail.com>, pgsql-hackers@lists.postgresql.org, 
	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>, Alena Rybakina <a.rybakina@postgrespro.ru>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CA%2BTgmobVWYnYDj1HZ--iqeKx%2Bn7zTgtYCar%2BYfZ0V6wiX-t0Mg%40mail.gmail.com>
Precedence: bulk

On Mon, Feb 17, 2025 at 3:08=E2=80=AFAM Ilia Evdokimov
<ilya.evdokimov@tantorlabs.com> wrote:
> You're right=E2=80=94floor shouldn't be used since it behaves differently=
 across
> platforms, as Tom also pointed out earlier. I like the idea of using %,
> but since the compiler doesn't allow this operation with double, we need
> to cast it to int64. I checked how nloops and ntuples are modified -
> they are only incremented by 1. So that the casting might be safe. If I
> missed anything or if there's a reason why this casting wouldn't be
> safe, please let me know.

What I've been advocating for is just:

if (nloops > 1)

Instead of:

if (nloops > 1 && rows_is_fractonal)

I don't think it's really safe to just cast a double back to int64. In
practice, the number of tuples should never be large enough to
overflow int64, but if it did, this result would be nonsense. Also, if
the double ever lost precision, the result would be nonsense. If we
want to have an exact count of tuples, we ought to change ntuples and
ntuples2 to be uint64. But I don't think we should do that in this
patch, because that adds a whole bunch of new problems to worry about
and might cause us to get nothing committed. Instead, I think we
should just always show two decimal digits if there's more than one
loop.

That's simpler than what the patch currently does and avoids this
problem. Perhaps it's objectionable for some other reason, but if so,
can somebody please spell out what that reason is so we can talk about
it?

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