On Wed, Feb 19, 2025 at 9:01 AM Ilia Evdokimov <ilya.evdoki...@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
