Re: Wrong rows count in EXPLAIN - Mailing list pgsql-hackers

From David Rowley
Subject Re: Wrong rows count in EXPLAIN
Date
Msg-id CAApHDvom=XXbPf4fJ4kJp1gK=QxMjFseCO69MNEE0JB-xPehEg@mail.gmail.com
Whole thread Raw
In response to Re: Wrong rows count in EXPLAIN  (Andrey Borodin <x4mmm@yandex-team.ru>)
List pgsql-hackers
On Wed, 27 Apr 2022 at 21:08, Andrey Borodin <x4mmm@yandex-team.ru> wrote:
> Which Postgres version do you use?

3d351d91 changed things so we could tell the difference between a
relation which was analyzed and is empty vs a relation that's never
been analyzed. That's why you're not seeing the same behaviour as the
OP.

Tom's commit message [1] also touches on the "safety measure". Here
he's referring to the 2550 estimate, or more accurately, 10 pages
filled with tuples of that width.  This is intended so that newly
created tables that quickly subsequently are loaded with data then
queried before auto-analyze gets a chance to run are not assumed to be
empty.  The problem, if we assumed these non-analyzed tables were
empty, would be that the planner would likely choose plans containing
nodes like Seq Scans and non-parameterized Nested Loops rather than
maybe Index Scans and Merge or Hash joins. The 10-page thing is aimed
to try and avoid the planner from making that mistake.  Generally, the
planner underestimating the number of rows causes worse problems than
when it overestimates the row counts. So 10 seems much better than 0.

David

[1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=3d351d916b20534f973eda760cde17d96545d4c4



pgsql-hackers by date:

Previous
From: Andrey Borodin
Date:
Subject: Re: Wrong rows count in EXPLAIN
Next
From: Alvaro Herrera
Date:
Subject: Re: bogus: logical replication rows/cols combinations