Message-ID: <f428e80d-8607-4a9d-950c-be9600f24904@gmail.com>
Date: Sat, 15 Feb 2025 09:46:13 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: explain analyze rows=%.0f
To: Robert Haas <robertmhaas@gmail.com>,
 Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>
Cc: pgsql-hackers@lists.postgresql.org, 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>
References: <CA+TgmoZv8DvmeQHQAX+rkn68id2N+DoUhFZB36d-_w1tyAeqeA@mail.gmail.com>
 <55695d15-c738-4401-8883-58bc855c9b03@tantorlabs.com>
 <58bb3a5b-c92a-408c-b02a-f47aedc1c0e2@tantorlabs.com>
 <CAFY6G8f6Sdu9cvfF2NYWWZMHD0ecTCPuNT7VktPH5NwxY7hcog@mail.gmail.com>
 <70bc1af0-6910-4f71-84ba-fa02095fe9ba@tantorlabs.com>
 <CAFY6G8dgp494Xi2+VUUyM2CvuSQ+3nnzWi44gURWbCHjEWW89g@mail.gmail.com>
 <fc28108a-8e7e-4f7d-b8f4-0bcc1581650d@tantorlabs.com>
 <CA+Tgmobgkh5CW=4Xpejw9nR6Onv8SZh0nnr+=HmNAFyyHZb0eg@mail.gmail.com>
 <3212947.1739306803@sss.pgh.pa.us>
 <eb73d4e1-4235-41b5-90a8-b0196550f62b@gmail.com>
 <CA+TgmobT9gPQLtw143oGnKVNtaOrTDOy+ZbLfe18MVZ9POjaWg@mail.gmail.com>
 <3365160.1739385615@sss.pgh.pa.us>
 <0e4c813a-18eb-41e2-8edb-89b78d43c82d@gmail.com>
 <CA+TgmoYzawdq40C5cN==LRPBvQChZ7t5XxH6wv+zMxnyM7LjBQ@mail.gmail.com>
 <e434311c-0f84-4c2b-a10d-ecb67f1ec19d@tantorlabs.com>
 <CA+TgmobfeePej0uNfbLy0v6jUrB3D9m1Kh+QQ40_-A9KQjkqUw@mail.gmail.com>
Content-Language: en-US
From: Andrei Lepikhov <lepihov@gmail.com>
In-Reply-To: <CA+TgmobfeePej0uNfbLy0v6jUrB3D9m1Kh+QQ40_-A9KQjkqUw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/f428e80d-8607-4a9d-950c-be9600f24904%40gmail.com>
Precedence: bulk

On 13/2/2025 21:42, Robert Haas wrote:
> On Thu, Feb 13, 2025 at 4:05 AM Ilia Evdokimov
> <ilya.evdokimov@tantorlabs.com> wrote:
>> 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.
> 
> Anyone else have an opinion on this? I see Ilia's point, but a
> non-equality join is probably an atypical case.
For me, it is ok: it demonstrates the feature and may legally happen. 
But this patch should be the second one, isn't it?
> 
>> 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.
> 
> This still has the HAS_DECIMAL() thing to which I objected.
I don't understand why using math.h and the floor() routine is 
necessary. I personally prefer x%y!=0 expression.

-- 
regards, Andrei Lepikhov