Re: Extended Statistics set/restore/clear functions.
| От | Michael Paquier |
|---|---|
| Тема | Re: Extended Statistics set/restore/clear functions. |
| Дата | |
| Msg-id | aQxb0rHuckPSBeLO@paquier.xyz обсуждение исходный текст |
| Ответ на | Re: Extended Statistics set/restore/clear functions. (Corey Huinker <corey.huinker@gmail.com>) |
| Ответы |
Re: Extended Statistics set/restore/clear functions.
|
| Список | pgsql-hackers |
On Wed, Nov 05, 2025 at 01:38:56AM -0500, Corey Huinker wrote: > Paquier's response got sidetracked because of an errant subject line > change, so I will try to recap: That was a typo that found its way into the email subject. Sorry about that, that broke gmail's tracking at least. > in that off-list discussion I proposed (though I was mostly echoing what I > thought Paquier wanted): > > 1. pg_ndistinct output function change. > 2. pg_ndistinct input function addition. > 3. pg_dependencies output function change > 4. pg_dependencies input function > 5. Expose attribute statistics function and rename them attstat_* or > statatt_* (edit: and fix lack of comments on the enums and arrays) > 6. pg_restore_extended_stats > 7. pg_dump with no ability to fetch old-format pg_ndistinct/pg_dependences. > (edit: and fix inherited bug) > 8. pg_dump working back as far as possible Thanks. I have begun reviewing it (more a bit later, still need to study more the structure of the code). For now, I have extracted some of the comment changes in 0005 and applied these independently. > Given that the pg_dump code no longer seems as bad, and Tomas is very much > in support of it, I've opted not to split out steps 7/8. That sounds like a way forward to me, then, in terms of using a new format and make pg_dump intelligent enough to deal with it based on what's in the past versions. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: