Corey Huinker <corey.huin...@gmail.com> writes: > On Sun, Mar 31, 2024 at 2:41 PM Tom Lane <t...@sss.pgh.pa.us> wrote: >> There's a bigger issue though: AFAICS this patch set does nothing >> about dumping extended statistics. I surely don't want to hold up >> the patch insisting that that has to happen before we can commit the >> functionality proposed here. But we cannot rip out pg_upgrade's >> support for post-upgrade ANALYZE processing before we do something >> about extended statistics, and that means it's premature to be >> designing any changes to how that works. So I'd set that whole >> topic on the back burner.
> So Extended Stats _were_ supported by earlier versions where the medium of > communication was JSON. However, there were several problems with adapting > that to the current model where we match params to stat types: > * Several of the column types do not have functional input functions, so we > must construct the data structure internally and pass them to > statext_store(). > * The output functions for some of those column types have lists of > attnums, with negative values representing positional expressions in the > stat definition. This information is not translatable to another system > without also passing along the attnum/attname mapping of the source system. I wonder if the right answer to that is "let's enhance the I/O functions for those types". But whether that helps or not, it's v18-or-later material for sure. > At least three people told me "nobody uses extended stats" and to just drop > that from the initial version. I can't quibble with that view of what has priority. I'm just suggesting that redesigning what pg_upgrade does in this area should come later than doing something about extended stats. regards, tom lane