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
tocompute total rows. Maybe this was obvious to others before, but now that we are displaying rows as a fraction, we
shouldexplicitly 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
theindex 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
achievedusing 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
keepsthe execution plan nearly unchanged. While the estimated and actual average row counts become slightly rounded, I
don'tsee 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.
> 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.
--
Robert Haas
EDB: http://www.enterprisedb.com
