po 26. 6. 2023 v 19:48 odesílatel James Coleman <jtc331@gmail.com> napsal:
On Mon, Jun 26, 2023 at 1:45 PM Pavel Stehule <pavel.stehule@gmail.com> wrote: > > > > po 26. 6. 2023 v 19:43 odesílatel Pavel Stehule <pavel.stehule@gmail.com> napsal: >> >> Hi >> >> po 26. 6. 2023 v 19:41 odesílatel James Coleman <jtc331@gmail.com> napsal: >>> >>> Hello, >>> >>> Have we ever discussed running an analyze immediately after creating a table? >>> >>> Consider the following: >>> >>> create table stats(i int, t text not null); >>> explain select * from stats; >>> Seq Scan on stats (cost=0.00..22.70 rows=1270 width=36 >>> analyze stats; >>> explain select * from stats; >>> Seq Scan on stats (cost=0.00..0.00 rows=1 width=36) >>> >>> Combined with rapidly increasing error margin on row estimates when >>> adding joins means that a query joining to a bunch of empty tables >>> when a database first starts up can result in some pretty wild plan >>> costs. >>> >>> This feels like a simple idea to me, and so I assume people have >>> considered it before. If so, I'd like to understand why the conclusion >>> was not to do it, or, alternatively if it's a lack of tuits. >> >> >> I like this. On the second hand, described behaviour is designed for ensuring of back compatibility. > > > if you break this back compatibility, then the immediate ANALYZE is not necessary
I don't follow what backwards compatibility you're referencing. Could you expand on that?
Originally, until the table had minimally one row, the PostgreSQL calculated with 10 pages. It was fixed (changed) in PostgreSQL 14.