On Thu, Feb 13, 2025 at 4:05 AM Ilia Evdokimov <ilya.evdoki...@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. > 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
