On Wed, Feb 19, 2025 at 9:01 AM 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=100 means the same number of rows on
> all iterations, while rows=100.00 indicates variation. Even if we
> describe this in the documentation, a user seeing rows=100.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=10..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?
--
Robert Haas
EDB: http://www.enterprisedb.com
