MIME-Version: 1.0
References: 
 <CA+TgmoZv8DvmeQHQAX+rkn68id2N+DoUhFZB36d-_w1tyAeqeA@mail.gmail.com>
 <CA+Tgmoaob_3aNF5S49WFoJs6Rb37rNnd5WH_e9nXAn_jtWWCLQ@mail.gmail.com>
 <3737950.1740182671@sss.pgh.pa.us>
 <CA+TgmobXwtS0ncAVfukE-Uhhy8Zt5rQWwQb2WHBcSop8r4Lcgw@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>
In-Reply-To: <db14cd95-f00d-4824-aebb-81c7e5a7ca08@tantorlabs.com>
From: Robert Haas <robertmhaas@gmail.com>
Date: Mon, 31 Mar 2025 13:35:49 -0400
Message-ID: 
 <CA+TgmoZz-t4swNuD--8brJi69b4ZAJ6riamd6hVJmvNL0L5=wA@mail.gmail.com>
Subject: Re: explain analyze rows=%.0f
To: Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>
Cc: Matthias van de Meent <boekewurm+postgres@gmail.com>,
 Tom Lane <tgl@sss.pgh.pa.us>,
	Andrei Lepikhov <lepihov@gmail.com>, pgsql-hackers@lists.postgresql.org,
	Guillaume Lelarge <guillaume@lelarge.info>,
 Matheus Alcantara <matheusssilv97@gmail.com>,
	Alena Rybakina <a.rybakina@postgrespro.ru>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CA%2BTgmoZz-t4swNuD--8brJi69b4ZAJ6riamd6hVJmvNL0L5%3DwA%40mail.gmail.com>
Precedence: bulk

On Tue, Mar 11, 2025 at 5:58=E2=80=AFAM Ilia Evdokimov
<ilya.evdokimov@tantorlabs.com> wrote:
> In the stats_ext regression test, there is a function
> check_estimated_rows that returns actual rows as an integer. Currently,
> none of the test cases produce a non-zero fractional part in actual rows.
>
> The question is: should this function be modified to return a fractional
> number instead of an integer?
>
> Personally, I don=E2=80=99t see much value in doing so, because the purpo=
se of
> the test is to compare the estimated row count with the actual number of
> rows. It is also unlikely that there will be test cases where loops > 1,
> and the presence of a fractional part does not change the essence of the
> test.
>
> What do you think?

I suppose the way this is currently coded, it will have the effect of
extracting the integer part of the row estimate. That doesn't really
seem like a bad idea to me, so I'm not sure it's worth trying to
adjust anything here.

One thing that I just noticed, though, is that we added two decimal
places to the actual row count, but not the estimated row count. So
now we get stuff like this:

         ->  Seq Scan on pgbench_branches b  (cost=3D0.00..1.10 rows=3D10
width=3D364) (actual time=3D0.007..0.009 rows=3D10.00 loops=3D1)

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.

--=20
Robert Haas
EDB: http://www.enterprisedb.com