Re: explain analyze rows=%.0f

On 01.08.2023 23:29, Daniel Gustafsson wrote:
>> On 3 Jul 2023, at 18:34, Daniel Gustafsson <daniel@yesql.se> wrote:
>>
>>> On 8 Jun 2023, at 19:49, Ibrar Ahmed <ibrar.ahmad@gmail.com> wrote:
>>> On Mon, Mar 20, 2023 at 7:56 PM Gregory Stark (as CFM) <stark.cfm@gmail.com <mailto:stark.cfm@gmail.com>> wrote:
>>> This patch was marked Returned with Feedback and then later Waiting on
>>> Author. And it hasn't had any updates since January. What is the state
>>> on this feedback? If it's already done we can set the patch to Ready
>>> for Commit and if not do you disagree with the proposed changes?
>>>
>>> If there is a consensus to modify the test cases' output, I am willing to
>>> make the necessary changes and adjust the patch accordingly. However,
>>> if there is a preference to keep the output of certain test cases unchanged,
>>> I can rebase and modify the patch accordingly to accommodate those preferences.
>> As there hasn't been any other comments I suggest updating your patch to
>> address Tom's comments to see if we can make progress here.
> Since there hasn't been any updates here, and the thread has been stalled, I'm
> marking this returned with feedback.  Please feel free to resubmit a version of
> the patch addressing comments to a future CF.
>
> --
> Daniel Gustafsson
>
>
>

Hi everybody,

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. For example, if there is 1 tuple over 100 loops, the 
average is 0.01 rows per loop, but as displayed it simply looks like zero.

To clarify this situation, it has been suggested that display rows with 
two decimal places in scenarios where 'loops > 1 && ntuples < loops'. In 
other words, show something like 'rows = 0.01' instead of 'rows=0'. This 
minor change would make it evident that rows did occur, just very 
infrequently.

For all other cases, the current formatting would remain the same. This 
approach aims to provide a more nuanced understanding of query execution 
behavior without introducing unnecessary complexity or false precision.

I would appreciate any thoughts or feedback on this proposal.

--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.