Re: explain analyze rows=%.0f

Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>

From: Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>
To: pgsql-hackers@lists.postgresql.org
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Matheus Alcantara <matheusssilv97@gmail.com>, Guillaume Lelarge <guillaume@lelarge.info>, Daniel Gustafsson <daniel@yesql.se>, Ibrar Ahmed <ibrar.ahmad@gmail.com>, "Gregory Stark (as CFM)" <stark.cfm@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>, Justin Pryzby <pryzby@telsasoft.com>, Peter Geoghegan <pg@bowt.ie>, vignesh C <vignesh21@gmail.com>, "David G. Johnston" <david.g.johnston@gmail.com>, Alena Rybakina <a.rybakina@postgrespro.ru>, Andrei Lepikhov <lepihov@gmail.com>, Robert Haas <robertmhaas@gmail.com>
Date: 2025-02-13T09:05:55Z
Lists: pgsql-hackers

Attachments

On 12.02.2025 22:56, Robert Haas wrote:
> On Wed, Feb 12, 2025 at 2:55 PM Andrei Lepikhov<lepihov@gmail.com>  wrote:
>> On 13/2/2025 01:40, Tom Lane wrote:
>>> I was idly speculating yesterday about letting the Ryu code print
>>> the division result, so that we get a variable number of digits.
>>> Realistically, that'd probably result in many cases in more digits
>>> than anybody wants, so it's not a serious proposal.  I'm cool with
>>> the fixed-two-digits approach to start with.
>> Okay, since no one else voted for the meaningful-numbers approach, I
>> would say that fixed size is better than nothing. It may cover some of
>> my practical cases, but unfortunately, not the most problematic ones.
> I don't love it either, but I do think it is significantly better than nothing.
>


I'm in favor of having some improvement rather than nothing at 
all—otherwise, we might never reach a consensus.

1. Documentation 
(v9-0001-Clarify-display-of-rows-as-decimal-fractions-DOC.patch)

One thing that bothers me is that the documentation explains how to 
compute total time, but it does not clarify how to compute total rows. 
Maybe this was obvious to others before, but now that we are displaying 
|rows| as a fraction, we should explicitly document how to interpret it 
alongside total time.

I believe it would be helpful to show a non-integer rows value in an 
example query. However, to achieve this, we need the index scan results 
to vary across iterations. One way to accomplish this is by using the 
condition t1.unique2 > t2.unique2. Additionally, I suggest making loops 
a round number (e.g., 100) for better readability, which can be achieved 
using t1.thousand < 10. The final query would look like this:

EXPLAIN ANALYZE SELECT *
FROM tenk1 t1, tenk2 t2
WHERE t1.thousand < 10 AND t1.unique2 > t2.unique2;

I believe this is an ideal example for the documentation because it not 
only demonstrates fractional rows, but also keeps the execution plan 
nearly unchanged. While the estimated and actual average row counts 
become slightly rounded, I don't see another way to ensure different 
results for each index scan.

I'm open to any feedback or suggestions for a better example to use in 
the documentation or additional explaining fractional rows in the text.

2. Code and tests 
(v9-0002-Clarify-display-of-rows-as-decimal-fractions.patch)

I left the code and tests unchanged since we agreed on a fixed format of 
two decimal places.

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

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.