Re: Analyze on table creation?
| От | James Coleman |
|---|---|
| Тема | Re: Analyze on table creation? |
| Дата | |
| Msg-id | CAAaqYe_JNBT+yNp0y-YJoNyo351M79OgV-7qreH9_gJe2ntg9Q@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Analyze on table creation? (Pavel Stehule <pavel.stehule@gmail.com>) |
| Ответы |
Re: Analyze on table creation?
|
| Список | pgsql-hackers |
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? Regards, James Coleman
В списке pgsql-hackers по дате отправления: