Re: Statistics Import and Export - Mailing list pgsql-hackers

From Corey Huinker
Subject Re: Statistics Import and Export
Date
Msg-id CADkLM=fJJKjFun6fHSO1nBQTbtPXxGTSGrRsJiuXgVQRYPLadA@mail.gmail.com
Whole thread Raw
In response to Re: Statistics Import and Export  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Statistics Import and Export
List pgsql-hackers
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.

That was Stephen's take as well, and I agreed given that I had to throw the kitchen-sink of source-side oid mappings (attname, types, collatons, operators) into the JSON to work around the limitation.
 
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.

I mostly agree, with the caveat that pg_upgrade's existing message saying that optimizer stats were not carried over wouldn't be 100% true anymore.
 

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Statistics Import and Export
Next
From: "Imseih (AWS), Sami"
Date:
Subject: Re: Psql meta-command conninfo+