Re: explain analyze rows=%.0f

Ibrar Ahmed <ibrar.ahmad@gmail.com>

From: Ibrar Ahmed <ibrar.ahmad@gmail.com>
To: Greg Stark <stark@mit.edu>
Cc: vignesh C <vignesh21@gmail.com>, "David G. Johnston" <david.g.johnston@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Robert Haas <robertmhaas@gmail.com>, Simon Riggs <simon@2ndquadrant.com>, Ron Mayer <rm_pg@cheapcomplexdevices.com>, Euler Taveira de Oliveira <euler@timbira.com>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2022-07-08T18:12:47Z
Lists: pgsql-hackers
On Thu, Jul 7, 2022 at 10:53 PM Greg Stark <stark@mit.edu> wrote:

> > -               ->  Parallel Seq Scan on tenk1 (actual rows=1960
> loops=50)
> > +               ->  Parallel Seq Scan on tenk1 (actual rows=1960.00
>
> At the not inconsiderable risk of bike-shedding....
>
> I'm wondering if printing something like 0.00 will be somewhat
> deceptive when the real value is non-zero but less than 1 row per 200
> loops. I wonder if the number of decimal places should be calculated
> to produce a minimum of one non-zero digit for non-zero values.
>
> --
> greg
>

+               ->  Parallel Seq Scan on tenk1 (actual rows=1960.00

I have added a new check to remove any ".00" from the output because in
the case of parallel queries we are getting that. Secondly, it is
disturbing many test case outputs.

-- 
Ibrar Ahmed

Commits

  1. EXPLAIN: Always use two fractional digits for row counts.

  2. Adjust EXPLAIN test case to filter out "Actual Rows" values.

  3. Allow EXPLAIN to indicate fractional rows.

  4. Fix pgbench performance issue induced by commit af35fe501.