Re: Statistics Import and Export
От | Jeff Davis |
---|---|
Тема | Re: Statistics Import and Export |
Дата | |
Msg-id | be7de51af6e969d501f69426c7137af6bde17fdc.camel@j-davis.com обсуждение исходный текст |
Ответ на | Statistics Import and Export (Corey Huinker <corey.huinker@gmail.com>) |
Ответы |
Re: Statistics Import and Export
Re: Statistics Import and Export |
Список | pgsql-hackers |
On Tue, 2024-09-17 at 05:02 -0400, Corey Huinker wrote: > > I've taken most of Jeff's work, reincorporated it into roughly the > same patch structure as before, and am posting it now. I have committed the import side of this patch series; that is, the function calls that can load stats into an existing cluster without the need to ANALYZE. The pg_restore_*_stats() functions are designed such that pg_dump can emit the calls. Some design choices of the functions worth noting: (a) a variadic signature of name/value pairs rather than ordinary SQL arguments, which makes it easier for future versions to interpret what has been output from a previous version; and (b) many kinds of errors are demoted to WARNINGs, to allow some statistics to be set for an attribute even if other statistics are malformed (also a future-proofing design); and (c) we are considering whether to use an in-place heap update for the relation stats, so that a large restore doesn't bloat pg_class -- I'd like feedback on this idea The pg_set_*_stats() functions are designed for interactive use, such as tweaking statistics for planner testing, experimentation, or reproducing a plan outside of a production system. The aforementioned design choices don't make a lot of sense in this context, so that's why the pg_set_*_stats() functions are separate from the pg_restore_*_stats() functions. But there's a lot of overlap, so it may be worth discussing again whether we should only have one set of functions. Regards, Jeff Davis
В списке pgsql-hackers по дате отправления: