Re: Analyze on table creation?

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: Analyze on table creation?
Дата
Msg-id CAFj8pRD4mWpDTnVJpP5EMThcn_Az1xiYhkNH=738R_6W3czxpA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Analyze on table creation?  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: Analyze on table creation?  (James Coleman <jtc331@gmail.com>)
Список pgsql-hackers


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

 

Regards

Pavel
 


Regards,
James Coleman


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: Analyze on table creation?
Следующее
От: James Coleman
Дата:
Сообщение: Re: Analyze on table creation?