From: Tom Lane <tgl@sss.pgh.pa.us>
To: Corey Huinker <corey.huinker@gmail.com>
cc: Magnus Hagander <magnus@hagander.net>, Jeff Davis <pgsql@j-davis.com>,
        Stephen Frost <sfrost@snowman.net>,
        Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>,
        Matthias van de Meent <boekewurm+postgres@gmail.com>,
        Peter Smith <smithpb2250@gmail.com>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
        Tomas Vondra <tomas.vondra@enterprisedb.com>
Subject: Re: Statistics Import and Export
In-reply-to: 
 <CADkLM=dHMSV=0r-hssUAksYXgi5ugDpSC9xF9mV88h2x9fjCBw@mail.gmail.com>
References: <Zei1xMGH8SJS9yoc@tamriel.snowman.net>
 <54f190b6c757da2a33cce811949e9dd9601fcba7.camel@j-davis.com>
 <1632327b74a734f8c434eb75e824160d2b06a697.camel@j-davis.com>
 <CADkLM=dOUfTtpmE70mx5SmdEs11hic61G-wPa45pB1iC3NRABg@mail.gmail.com>
 <16412b8b7ae443cb7470006beff3011927048860.camel@j-davis.com>
 <CADkLM=cq1n2wbxhV23pOeUKReBPZxZyELDsDJ3VAxkYBSVAe0g@mail.gmail.com>
 <CADkLM=d_WYoFq75eoNHso+9EFDi=Q2BtCmxQYMjrgLL4=v5dxw@mail.gmail.com>
 <1b1bd1ec39ab3de09a17bf7b241021067e5bd63c.camel@j-davis.com>
 <CADkLM=eJXPQD=pWwwm+4Y48haiMmznB8dCECNMrwr59niY8ESw@mail.gmail.com>
 <2bce855db8259c5672a09f863a307ca07b967b68.camel@j-davis.com>
 <CADkLM=dw=fkvPRmOw74UDYnLzXwkDyMSY1k2jsU5=xXBAj7Mpw@mail.gmail.com>
 <5e94c358caedf2a231dd71624c3578db7227a265.camel@j-davis.com>
 <CADkLM=dztWa9shWHyq=+rS9KvbZQ2v54tnOcYT+g8psf0B7w_A@mail.gmail.com>
 <CADkLM=fFwkd7VbO4SPCyX-2f-fyGraka5J+5fcp1QMrCefu68Q@mail.gmail.com>
 <CADkLM=cioQmOFh98qQmqVEkVPjLYszEhZtNtUbmmNAdHOSr3WQ@mail.gmail.com>
 <4afa70edab849ff1623!
 8d1100b6652404e9a4d9d.camel@j-davis.com>
 <CADkLM=e=_6dtacmrvd2NJWacOnQ3Zu5iaRZFgePL1=0L5-7P_w@mail.gmail.com>
 <3df03aa65aa6ea3a76582e1a792e422dc5c32ad3.camel@j-davis.com>
 <CAOuzzgpfm9hROr_g8LouvpOeqv4yxk3qXPXU9Sn2nnqzPpP5UA@mail.gmail.com>
 <718fa933c2c58d0ecc61995ab5c7ca1fe78d6369.camel@j-davis.com>
 <CADkLM=f9FOu9Z2GT1cbtRaffDvtXyUOuv2HMVw0=phYe2T2D9w@mail.gmail.com>
 <CABUevEz1gLOkWSh_Vd9LQh-JM4i=Mu7PVT9ffc77TmH0Zh3TzA@mail.gmail.com>
 <CADkLM=dTY5bkMB4WO0aTYEOP=re0_QjWfYyPd-A5-BvEQdn9cA@mail.gmail.com>
 <790136.1711910460@sss.pgh.pa.us>
 <CADkLM=dHMSV=0r-hssUAksYXgi5ugDpSC9xF9mV88h2x9fjCBw@mail.gmail.com>
Comments: In-reply-to Corey Huinker <corey.huinker@gmail.com>
	message dated "Sun, 31 Mar 2024 18:37:28 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <832589.1711925053.1@sss.pgh.pa.us>
Content-Transfer-Encoding: 8bit
Date: Sun, 31 Mar 2024 18:44:13 -0400
Message-ID: <832590.1711925053@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/832590.1711925053%40sss.pgh.pa.us>
Precedence: bulk

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