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.
Thanks for your patch, this looks like a very interesting feature that I'd like to see in a future release.
It did a quick run: patch OK, make OK, make install OK, but make check fails quite a lot on partition_prune.sql.
I guess it would need some work on partition_prune.sql tests and perhaps also on the docs.
