Thanks for the new patch version.
-- v7-0001-Clarify-display-of-rows-and-loops-as-decimal-fraction.patch
> + if (nloops > 1 && planstate->instrument->ntuples < nloops)
> + appendStringInfo(es->str," rows=%.2f loops=%.2f)", rows,
> nloops);
>
Sorry, but why do the 'loops' need to be changed? IIUC the issue is
only with the
rows field? When testing this patch I got some results similar with this:
Index Scan using t_a_idx on t (cost=0.14..0.28 rows=1 width=8)
(actual time=0.049..0.049 rows=0.50 loops=2.00)
> When the total number of returned tuples is less than the number of
> loops currently shows 'rows = 0'. This can mislead users into thinking
> that no rows were returned at all, even though some might have appeared
> occasionally.
>
I think that this can happen when the returned rows and the loops are small
enough to result in a 'row' value like 0.00045? I'm not sure if we have
"bigger" values (e.g 1074(ntuples) / 117(nloops) which would result in 9.17
rows) this would also be true, what do you think? If you could provide
an example of this case would be great!
- executing the index scans on <literal>tenk2</literal>.
+ executing the index scans on <literal>tenk2</literal>. If a subplan node
+ is executed multiple times and the average number of rows is less than one,
+ the rows and <literal>loops</literal> values are shown as a
decimal fraction
+ (with two digits after the decimal point) to indicate that some rows
+ were actually processed rather than simply rounding down to zero.
* I think that it would be good to mention what a 'row' value in
decimal means. For
example, if its says "0.1 rows" the user should assume that typically 0 rows
will be returned but sometimes it can return 1 or more.
* There are more spaces than necessary before "If a subplan node ..."
* Maybe wrap 'rows' with <literal> </literal>?
--
Matheus Alcantara
