MIME-Version: 1.0
References: 
 <CADkLM=coCVy92QkVUUTLdo5eO2bMDtwMrzRn_8miAhX+uPaqXg@mail.gmail.com>
 <CAA5RZ0vY5jHXQEOyUdjW7tPrXb9TY_bdr8ZpCRuALj1zU5DD_w@mail.gmail.com>
 <CADkLM=d8vuFzQSrV+8MfviK3-TyG8r45yEbnOUd6VJGEoyNmHA@mail.gmail.com>
 <CAA5RZ0tSYjO4Frt-SkpV1kmXn4jYTdVP-1XEMtFF2yJ9B4scDg@mail.gmail.com>
 <CADkLM=d=udo8pxPeLQA6Z2YKLMgTvJM_Uh2mYtsCE38fJ8xodw@mail.gmail.com>
 <CAA5RZ0uTxOgN-sfQMV5-3dwE9SqgS3_xf5zhj0Gp12TJtBuk5g@mail.gmail.com>
 <CADkLM=cz=bEvRRj0mSffMrVW56M=1O-KqavCZv19on-MQrkZwg@mail.gmail.com>
 <aateiqvWO53UjoNI@nathan> <aathGcXAIpiUSP_s@nathan>
 <CAA5RZ0vCuDDd6-H00aabjLri0yO_AMJQ4Lb4017pepqU5WNyFg@mail.gmail.com>
 <aa7sZcuRrlkeVJGX@nathan>
In-Reply-To: <aa7sZcuRrlkeVJGX@nathan>
From: Corey Huinker <corey.huinker@gmail.com>
Date: Mon, 9 Mar 2026 14:29:32 -0400
Message-ID: 
 <CADkLM=eUR5co+o3PU8M=Fo8rRynj4xf=PFtt2KisD96bdrPEOg@mail.gmail.com>
Subject: Re: Add starelid, attnum to pg_stats and leverage this in pg_dump
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Sami Imseih <samimseih@gmail.com>, pgsql-hackers@lists.postgresql.org
Content-Type: multipart/alternative; boundary="000000000000433a09064c9b96a9"
Archived-At: 
 <https://www.postgresql.org/message-id/CADkLM%3DeUR5co%2Bo3PU8M%3DFo8rRynj4xf%3DPFtt2KisD96bdrPEOg%40mail.gmail.com>
Precedence: bulk

--000000000000433a09064c9b96a9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 9, 2026 at 11:51=E2=80=AFAM Nathan Bossart <nathandbossart@gmai=
l.com>
wrote:

> On Mon, Mar 09, 2026 at 10:44:58AM -0500, Sami Imseih wrote:
> >> Oh, a question I forgot to ask: why wouldn't we do the same thing for
> >> pg_stats_ext and pg_stats_ext_exprs?
> >
> > [...]
> >
> > If we do add relid there, it will be for consistency only.
>
> It might be only for consistency for now, but it strikes me as something
> that could be handy down the road (in which case it'd be nice to minimize
> the number of versions that need a fallback).
>
> --
> nathan
>

You're both right. Currently, we fetch extended stats one at a time, thus
there's no _immediate_ need to do so.

But "why wait until there is a crisis" is solid reasoning and for that I
had already coded up the change. I did have one small problem in that
Michael Paquier had hoped that we could get the expr index (-1, -2, etc) on
the expressions as that was something that we at least briefly thought we'd
need for importing expression statistics. However the existing query uses a
SELECT unnest(a), unnest(b) pattern in it, and WITH ORDINALITY is not
allowed, and the workarounds I found seemed a bit tortured. Hence, I
decided to leave that out so as not to distract from the now accepted
patch, and with that out of the way I'll happily inflict that tortured SQL
on y'all.

--000000000000433a09064c9b96a9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Mar 9, =
2026 at 11:51=E2=80=AFAM Nathan Bossart &lt;<a href=3D"mailto:nathandbossar=
t@gmail.com">nathandbossart@gmail.com</a>&gt; wrote:<br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex">On Mon, Mar 09, 2026 at 10:44:58AM -05=
00, Sami Imseih wrote:<br>
&gt;&gt; Oh, a question I forgot to ask: why wouldn&#39;t we do the same th=
ing for<br>
&gt;&gt; pg_stats_ext and pg_stats_ext_exprs?<br>
&gt; <br>
&gt; [...]<br>
&gt; <br>
&gt; If we do add relid there, it will be for consistency only.<br>
<br>
It might be only for consistency for now, but it strikes me as something<br=
>
that could be handy down the road (in which case it&#39;d be nice to minimi=
ze<br>
the number of versions that need a fallback).<br>
<br>
-- <br>
nathan<br></blockquote><div><br></div><div>You&#39;re both right. Currently=
, we fetch extended stats one at a time, thus there&#39;s no _immediate_ ne=
ed to do so.<br><br></div><div>But &quot;why wait until there is a crisis&q=
uot; is solid reasoning and for that I had already coded up the change. I d=
id have one small problem in that Michael Paquier had hoped that we could g=
et the expr index (-1, -2, etc) on the expressions as that was something th=
at we at least briefly thought we&#39;d need for importing expression stati=
stics. However the existing query uses a SELECT unnest(a), unnest(b) patter=
n in it, and WITH ORDINALITY is not allowed, and the workarounds I found se=
emed a bit tortured. Hence, I decided to leave that out so as not to distra=
ct from the now accepted patch, and with that out of the way I&#39;ll happi=
ly inflict that tortured SQL on y&#39;all.=C2=A0</div></div></div>

--000000000000433a09064c9b96a9--