Corey Huinker <corey.huinker@gmail.com> writes:
> On Sun, Mar 31, 2024 at 2:41 PM Tom Lane <tgl@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