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
- v9-0001-Clarify-display-of-rows-as-decimal-fractions-DOC.patch (text/x-patch) patch v9-0001
- v9-0002-Clarify-display-of-rows-as-decimal-fractions.patch (text/x-patch) patch v9-0002
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
-
EXPLAIN: Always use two fractional digits for row counts.
- 95dbd827f2ed 18.0 landed
-
Adjust EXPLAIN test case to filter out "Actual Rows" values.
- 44cbba9a7f51 18.0 cited
-
Allow EXPLAIN to indicate fractional rows.
- ddb17e387aa2 18.0 landed
-
Fix pgbench performance issue induced by commit af35fe501.
- fb056564ec5b 18.0 cited