From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tomas@vondra.me>
cc: Alexandra Wang <alexandra.wang.oss@gmail.com>,
        jian he <jian.universality@gmail.com>,
        pgsql-hackers@lists.postgresql.org,
        Andrei Lepikhov <lepihov@gmail.com>,
        Corey Huinker <corey.huinker@gmail.com>, hs@cybertec.at,
        Jeff Davis <pgsql@j-davis.com>
Subject: Re: Is there value in having optimizer stats for joins/foreignkeys?
In-reply-to: <48aaff7c-5f37-44e1-9df0-859b168d8b1f@vondra.me>
References: 
 <CADkLM=cUwMftPLFq0iD6-qKRyNiRM2HZGYVp6=0noxA8GfuEtA@mail.gmail.com>
 <e9165403-7b0e-4c01-96d0-b73512ce359d@vondra.me>
 <3c477f2f-10e4-4705-bb21-90ccbe67e9d2@gmail.com>
 <d079f515-db2c-43f3-a11f-ceff7b1616c9@vondra.me>
 <CAK98qZ2ySno00SApwj3X_MgN4iuBzKaXKXOY+U3jaFqTxPS8Tg@mail.gmail.com>
 <CAK98qZ0Vr4D3usesj_qpNFAH1=7NKX=bR9bNRNM7tdnk5KWHDw@mail.gmail.com>
 <CAK98qZ2TveWY34VBw8LmQUEq2GUrPLhsaYYORgDAA5VZybyS5w@mail.gmail.com>
 <CAK98qZ3TGXKcudcnyEhGuMUiru36m=Vm=Zm5Gyug0h+VyxmD0w@mail.gmail.com>
 <CACJufxFOe4rx=J+0+=_g+K=bnhxs1OUdMJCgQ+tV0KdkQ_2aeQ@mail.gmail.com>
 <CAK98qZ2mMJ3Nvx9U1S9N9Put1bb=iOgy8vFdp=rfjfta4wJ2AQ@mail.gmail.com>
 <CAK98qZ3ASXEBuftvd=SxPwLOXgo=2-88SyZyLxXf3k4HfDKKsw@mail.gmail.com>
 <CAK98qZ397f5xEkNgqEoeZTbXBnr7h665wZMvGJOnok+ch+XWSA@mail.gmail.com>
 <24247.1779395113@sss.pgh.pa.us>
 <910a4628-720a-4912-af8f-8b5a96a0b336@vondra.me>
 <2468544.1779721437@sss.pgh.pa.us>
 <CAK98qZ0_4Kodyemk0Tdmew=YG8jeHQ=wzOydQws4s99A1X2h5g@mail.gmail.com>
 <48aaff7c-5f37-44e1-9df!
 0-859b168d8b1f@vondra.me>
Comments: In-reply-to Tomas Vondra <tomas@vondra.me>
	message dated "Wed, 27 May 2026 21:08:34 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <711246.1779913876.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 27 May 2026 16:31:16 -0400
Message-ID: <711247.1779913876@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/711247.1779913876%40sss.pgh.pa.us>
Precedence: bulk

Tomas Vondra <tomas@vondra.me> writes:
> On 5/27/26 19:49, Alexandra Wang wrote:
>> One question about the pg_stats_ext view: currently it has two compleme=
ntary
>> columns:
>> =

>> - attnames (name[]) =E2=80=94 Names of the columns included in the stat=
istics object
>> - exprs (text[]) =E2=80=94 Expressions included in the statistics objec=
t
>> =

>> With stxkeys gone from the catalog, should the view:
>> (a) Stay as-is: keep attnames and exprs as separate columns with the sa=
me
>> semantics. Implemented via a helper function that extracts plain column
>> names from the unified stxexprs.
>> or
>> (b) Mirror the catalog: remove attnames, make exprs show all entries (b=
oth
>> column names and expressions together in one text[] array).

> My 2c: AFAIR there's no fundamental reason to keep those two lists
> separate, other than that expressions were "bolted on" later, after we
> already had stats on plain attributes. In hindsight, it might have been
> better to just unify the view back then, probably.

Yeah.  There are some other oddities that arise from that: expressions
get shoved to the end.  For example, if I put in

create statistics my_stats (mcv) on ten, (ten+four), four from tenk1;

pg_dump will regurgitate that as

CREATE STATISTICS public.my_stats (mcv) ON four, ten, (ten + four) FROM pu=
blic.tenk1;

and I see that that column ordering is consistent with what appears in
pg_stats_ext and perhaps other places.  I'd expect a rewritten version
to stop doing that and preserve the user-written column order.
So there are going to be some potential minor incompatibilities for
anything that is looking too closely at this view, and it seems to
me that it might be better for such code to fail noisily rather than
perhaps silently mis-associate stats with columns.

(It might be a good idea to have some test cases that exercise this
kind of scenario in pg_upgrade, especially now that we are trying to
transfer extended stats in upgrades...)

			regards, tom lane