Re: Statistics Import and Export
| От | Corey Huinker |
|---|---|
| Тема | Re: Statistics Import and Export |
| Дата | |
| Msg-id | CADkLM=dTY5bkMB4WO0aTYEOP=re0_QjWfYyPd-A5-BvEQdn9cA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Statistics Import and Export (Magnus Hagander <magnus@hagander.net>) |
| Ответы |
Re: Statistics Import and Export
Re: Statistics Import and Export |
| Список | pgsql-hackers |
That will make it *really* hard for any form of automation or drivers of this. The information needs to go somewhere where such tools can easily consume it, and an informational message during runtime (which is also likely to be translated in many environments) is the exact opposite of that.
Having given this some thought, I'd be inclined to create a view, pg_stats_missing, with the same security barrier as pg_stats, but looking for tables that lack stats on at least one column, or lack stats on an extended statistics object.
Table structure would be
Table structure would be
schemaname nametablename nameattnames text[]ext_stats text[]
The informational message, if it changes at all, could reference this new view as the place to learn about how well the stats import went.
vacuumdb might get a --missing-only option in addition to --analyze-in-stages.
For that matter, we could add --analyze-missing options to pg_restore and pg_upgrade to do the mopping up themselves.
В списке pgsql-hackers по дате отправления: