Re: Showing primitive index scan count in EXPLAIN ANALYZE (for skip scan and SAOP scans)

On 17.02.2025 20:56, Peter Geoghegan wrote:
> On Wed, Nov 27, 2024 at 8:36 AM Matthias van de Meent
> <boekewurm+postgres@gmail.com>  wrote:
>>> I think we should divide them because by dividing the total buffer usage by the number of loops, user finds the average buffer consumption per loop. This gives them a clearer picture of the resource intensity per basic unit of work.
>> I disagree; I think the whole "dividing by number of loops and
>> rounding up to integer" was the wrong choice for tuple count, as that
>> makes it difficult if not impossible to determine the actual produced
>> count when it's less than the number of loops. Data is lost in the
>> rounding/processing, and I don't want to have lost that data.
> I think that you're definitely right about this. I changed my mind (or
> changed it back to my original position) recently, when I noticed how
> bad the problem was with parallel index scans: nloops generally comes
> from the number of workers (including the leader) for parallel scans,
> and so it wasn't that hard to see "Index Searches: 0" with the latest
> version (the version that started to divide by nloops). Obviously,
> that behavior is completely ridiculous. Let's not do that.
>
> The precedent to follow here is "Heap Fetches: N" (in the context of
> index-only scans), which also doesn't divide by nloops. Likely because
> the same sorts of issues arise with heap fetches.
Yes, you are right, I agree with both of you.

-- 
Regards,
Alena Rybakina
Postgres Professional