Re: Statistics Import and Export

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: Statistics Import and Export
Дата
Msg-id 1d70aabacd379ed8f9a7db1bf4ca22d1f5cd943f.camel@j-davis.com
обсуждение исходный текст
Ответ на Re: Statistics Import and Export  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Statistics Import and Export  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Mon, 2024-04-22 at 16:19 -0400, Tom Lane wrote:
> Loading data without stats, and hoping
> that auto-analyze will catch up sooner not later, is exactly the
> current behavior that we're doing all this work to get out of.

That's the disconnect, I think. For me, the main reason I'm excited
about this work is as a way to solve the bad-plans-after-upgrade
problem and to repro planner issues outside of production. Avoiding the
need to ANALYZE at the end of a data load is also a nice convenience,
but not a primary driver (for me).

Should we just itemize some common use cases for pg_dump, and then
choose the defaults that are least likely to cause surprise?

As for the section, I'm not sure what to do about that. Based on this
thread it seems that SECTION_NONE (or a SECTION_STATS?) is easiest to
implement, but I don't understand the long-term consequences of that
choice.

Regards,
    Jeff Davis




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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: fix tablespace handling in pg_combinebackup
Следующее
От: Peter Smith
Дата:
Сообщение: Re: logicalrep_worker_launch -- counting/checking the worker limits