Re: Show 'Rows Removed by Filter' with two fractional digits in EXPLAIN

On 11/6/26 11:57, Andrei Lepikhov wrote:
> Since ddb17e387aa, EXPLAIN reports per-loop actual rows with two decimal digits.
> The neighbouring counters - Rows Removed by Filter, by Join Filter - are divided
> by nloops too, but are still printed with zero digits. In a parameterised inner
> side this makes the two numbers contradict each other, for example:
>
> -> Index Scan using tenk1_unique1 on tenk1 b (actual rows=0.90 loops=10)
> Index Cond: (unique1 = g.g)
> Filter: (ten <> 0)
> Rows Removed by Filter: 0
>
> The scan returned 0.90 rows per loop out of 1.00 fetched, yet the filter claims
> it removed nothing. See the attached patch for complete examples.

LGTM. Since these counters are also divided by nloops, it makes sense to
display them with two digits after the decimal point, just like actual rows.

> The patch is a single-line change in show_instrumentation_count() plus two
> tests. It is a concept, not a finished patch: I have not regenerated the other
> expected outputs, where many values will change from "N" to "N.00" - you can
> find a sketch for that in 0002-* file.

If we switch to fractional row counts, we should also remember to update
the relevant examples in the doc, including "Rows Removed by Filter",
"Rows Removed by Index Recheck", "Rows Removed by Conflict Filter",
"Rows Removed by Join Filter".

Regardless of whether we change this output format, it would be be
useful to document in the "Using EXPLAIN" section (perform.sgml), in the
paragraph describing "Rows Removed", that these counts are averages per
execution of the node. This is already the case, but the paragraph does
not mention it.

> Before going through that churn, I would
> like to hear whether people agree that these counters should follow the same
> rule as actual rows. The options I see are:
>
> 1. Always print two digits, as actual rows do now.
> 2. Leave the math to users and print exact totals without dividing by nloops.
>
> The second approach is a much bigger change, with obvious pros and cons.
> The first one is simpler and more conservative, and it is what the attached
> patch does. In [1], depesz describes how the switch to fractional actual rows
> affected his explain parser, and it needed only a small fix. So I expect this
> change to be similarly harmless for tools.
>
> Thoughts?
>
> [1]
> https://www.depesz.com/2025/02/28/waiting-for-postgresql-18-allow-explain-to-indicate-fractional-rows/

I also prefer the first option, as it is more conservative and keeps
these counters consistent with actual rows.

--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC,
https://tantorlabs.com/