MIME-Version: 1.0
References: <CA+TgmoZv8DvmeQHQAX+rkn68id2N+DoUhFZB36d-_w1tyAeqeA@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>
 <CA+TgmobVWYnYDj1HZ--iqeKx+n7zTgtYCar+YfZ0V6wiX-t0Mg@mail.gmail.com>
 <73e2440e-7d8b-4860-974d-931a93326d95@gmail.com> <7ab512ac-eed1-4fc8-9c5f-b42c0b0d313e@tantorlabs.com>
In-Reply-To: <7ab512ac-eed1-4fc8-9c5f-b42c0b0d313e@tantorlabs.com>
From: Robert Haas <robertmhaas@gmail.com>
Date: Fri, 21 Feb 2025 16:20:08 -0500
Message-ID: <CA+TgmoYp1KvG=7L7SjiRjJrXT8kEfH10kSGp54FQd03v19OwvA@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%2BTgmoYp1KvG%3D7L7SjiRjJrXT8kEfH10kSGp54FQd03v19OwvA%40mail.gmail.com>
Precedence: bulk

On Wed, Feb 19, 2025 at 9:01=E2=80=AFAM Ilia Evdokimov
<ilya.evdokimov@tantorlabs.com> wrote:
> The idea of indicating to the user that different iterations produced
> varying numbers of rows is quite reasonable. Most likely, this would
> require adding a new boolean field to the Instrumentation structure,
> which would track this information by comparing the rows value from the
> current and previous iterations.

Yep.

> However, there is a major issue: this case would be quite difficult to
> document clearly. Even with an example and explanatory text, users may
> still be confused about why rows=3D100 means the same number of rows on
> all iterations, while rows=3D100.00 indicates variation. Even if we
> describe this in the documentation, a user seeing rows=3D100.00 will most
> likely assume it represents an average of 100 rows per iteration and may
> still not realize that the actual number of rows varied.

I imagine this is a surmountable problem.

> If we want to convey this information more clearly, we should consider a
> more explicit approach. For example, instead of using a fractional
> value, we could display the minimum and maximum row counts observed
> during execution (e.g.,rows=3D10..20, formatting details could be
> discussed). However, in my opinion, this discussion is beyond the scope
> of this thread.

I quite agree. I think we've spent too much time on this already; this
idea was first proposed in 2009, and we just haven't gotten around to
doing anything about it. Redesigning the feature a few more times
(with an expanded scope) isn't going to make that better.

So, I've committed v11-0001. I'm not altogether convinced that
v11-0002 is necessary -- no portion of the documentation that it
modifies is falsified by the committed patch. Maybe we can just call
this one done for now and move on?

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