Message-ID: <ae90d15d-54e5-4caa-ba72-5bbed9b2c908@gmail.com>
Date: Tue, 1 Apr 2025 07:20:37 +0200
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: Matthias van de Meent <boekewurm+postgres@gmail.com>,
 Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@lists.postgresql.org,
 Guillaume Lelarge <guillaume@lelarge.info>,
 Matheus Alcantara <matheusssilv97@gmail.com>,
 Alena Rybakina <a.rybakina@postgrespro.ru>
References: <CA+TgmoZv8DvmeQHQAX+rkn68id2N+DoUhFZB36d-_w1tyAeqeA@mail.gmail.com>
 <3816053.1740190267@sss.pgh.pa.us>
 <CA+TgmoZp7LstKmDwyfUuB+6aFFhn0N3fv2QxTD=dkrxXVJ5dZA@mail.gmail.com>
 <CA+TgmoazzVHn8sFOMFAEwoqBTDxKT45D7mvkyeHgqtoD2cn58Q@mail.gmail.com>
 <40663fc5-edac-4b45-a2aa-a76976700ed9@tantorlabs.com>
 <CA+TgmoZxRP8cEhfdF27k600B_=8DXpj=8kiM7s_6qCHCqxQPmA@mail.gmail.com>
 <CA+TgmoapgkOFmezwVjJbs5Xq9F+Mfm9aNouBgTq_AuqQJkLYEg@mail.gmail.com>
 <f61cb18b-0e51-4350-b122-f2557e02c487@tantorlabs.com>
 <e02b5ba8-d879-4121-a21e-8a3928be337e@postgrespro.ru>
 <CAEze2Wiap5v-H-5QqGq-=DBG99CK-RgHpQUFaU6TENh_+zCh_w@mail.gmail.com>
 <CA+TgmobD4_fz4JnGkYey_2rsXi5mxucDPR2ot6rX9OoHBw+qhg@mail.gmail.com>
 <432c75b0-be5f-4836-b46b-98c505eaad28@postgrespro.ru>
 <CA+Tgmob2FcdNQnfv20hFHMiQjqsmak4NnkmxjNQnNpzzbowmgQ@mail.gmail.com>
 <db14cd95-f00d-4824-aebb-81c7e5a7ca08@tantorlabs.com>
 <CA+TgmoZz-t4swNuD--8brJi69b4ZAJ6riamd6hVJmvNL0L5=wA@mail.gmail.com>
Content-Language: en-AU
From: Andrei Lepikhov <lepihov@gmail.com>
In-Reply-To: <CA+TgmoZz-t4swNuD--8brJi69b4ZAJ6riamd6hVJmvNL0L5=wA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/ae90d15d-54e5-4caa-ba72-5bbed9b2c908%40gmail.com>
Precedence: bulk

On 3/31/25 19:35, Robert Haas wrote:
> But why isn't it just as valuable to have two decimal places for the
> estimate? I theorize that the cases that are really a problem here are
> those where the row count estimate is between 0 and 1 per row, and
> rounding to an integer loses all precision.
Issues I've ever seen were about zero rows number - we lose 
understanding of what the job the executor has done in the node - loops 
= 10000000 doesn't tell us any helpful information in that case.
Maybe in the next version, we replace the two fractional numbers rule 
with two valuable numbers. At least, it removes boring xxx.00 numbers 
from EXPLAIN.

-- 
regards, Andrei Lepikhov