Subject: Re: explain analyze rows=%.0f

From: Ibrar Ahmed <[email-masked]>
Date: Wed, 4 Jan 2023 20:04:53 +0500

On Sun, Nov 6, 2022 at 10:12 AM Tom Lane <[email-masked]> wrote:

> Robert Haas <[email-masked]> writes:
> > On Fri, Jul 22, 2022 at 6:47 AM Amit Kapila <[email-masked]>
> wr> ote:
> >> I feel the discussion has slightly deviated which makes it unclear
> >> whether this patch is required or not?
>
> > My opinion is that showing some fractional digits at least when
> > loops>1 would be better than what we have now. It might not be the
> > best thing we could do, but it would be better than doing nothing.
>
> Yeah, I think that is a reasonable compromise.
>
>
Thanks, I have modified everything as suggested, except one point

> I took a brief look through the patch, and I have some review
> comments:
>
> * Code like this is pretty awful:
>
>                 appendStringInfo(es->str,
>                                  (nloops == 1 || !HAS_DECIMAL(rows)) ?
>                                  " rows=%.0f loops=%.0f)" : " rows=%> .2f loops=%.0f)",
>                                  rows, nloops);
>
> Don't use variable format strings.  They're hard to read and they
> probably defeat compile-time checks that the arguments match the
> format string.  You could use a "*" field width instead, ie
>
>                 appendStringInfo(es->str,
>                                  " rows=%.*f loops=%.0f)",
>                                  (nloops == 1 || !HAS_DECIMAL(rows)) ?>  2 : 0,
>                                  rows, nloops);
>
> That'd also allow you to reduce the code churn you've added by
> splitting some appendStringInfo calls.
>
> * I'm fairly concerned about how stable this'll be in the buildfarm,
> in particular I fear HAS_DECIMAL() is not likely to give consistent
> results across platforms.  I gather that an earlier version of the patch
> tried to check whether the fractional part would be zero to two decimal
> places, rather than whether it's exactly zero.  Probably want to put
> back something like that.
>
> * Another thought is that the non-text formats tend to prize output
> consistency over readability, so maybe we should just always use 2
> fractional digits there, rather than trying to minimize visible changes.
>
> In that, we need to adjust a lot of test case outputs.

* We need some doc adjustments, surely, to explain what the heck this
> means.

>                         regards, tom lane

-- 
Ibrar Ahmed

---

From: "Gregory Stark (as CFM)" <[email-masked]>
Date: Mon, 20 Mar 2023 10:56:13 -0400

> > format string. You could use a "*" field width instead, ie
...

> > * We need some doc adjustments, surely, to explain what the heck this

That sounds like three points :) But they seem like pretty good
arguments to me and straightforward if a little tedious to adjust.

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?

It's actually the kind of code cleanup changes I'm reluctant to bump a
patch for. It's not like a committer can't make these kinds of changes
when committing. But there are so many patches they're likely to just
focus on a different patch when there are adjustments like this
pending.

-- 
Gregory Stark
As Commitfest Manager