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>
 <CADkLM=eUR5co+o3PU8M=Fo8rRynj4xf=PFtt2KisD96bdrPEOg@mail.gmail.com>
 <CAA5RZ0s674FM8vcEqr+DUVjWOpYSPS-rG8uANdJKEnSyo+tObA@mail.gmail.com>
In-Reply-To: 
 <CAA5RZ0s674FM8vcEqr+DUVjWOpYSPS-rG8uANdJKEnSyo+tObA@mail.gmail.com>
From: Corey Huinker <corey.huinker@gmail.com>
Date: Mon, 9 Mar 2026 15:28:40 -0400
Message-ID: 
 <CADkLM=cYLk7bi3QVMBGWsFEzNfpqyV1Es3tWCwfERS88MdULWQ@mail.gmail.com>
Subject: Re: Add starelid, attnum to pg_stats and leverage this in pg_dump
To: Sami Imseih <samimseih@gmail.com>
Cc: Nathan Bossart <nathandbossart@gmail.com>,
 pgsql-hackers@lists.postgresql.org
Content-Type: multipart/alternative; boundary="000000000000ae4c4b064c9c69ef"
Archived-At: 
 <https://www.postgresql.org/message-id/CADkLM%3DcYLk7bi3QVMBGWsFEzNfpqyV1Es3tWCwfERS88MdULWQ%40mail.gmail.com>
Precedence: bulk

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

On Mon, Mar 9, 2026 at 2:56=E2=80=AFPM Sami Imseih <samimseih@gmail.com> wr=
ote:

> >> 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 i=
s
> 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.
>
> Can we add the tableid  for now (see 0003) and follow-up with another
> thread with the sql changes to pg_dump?
>

Presently, I don't think we make any changes to pg_dump, unless Nathan
feels strongly that we should. If and when the need for oid-based fetching
of extended stats becomes necessary, we'll at least have a couple versions
where the catalog already had the oids handy.


>
> I also corrected v2-0001. The docs were still referencing "starlid"
> instead of "tableid"
>

I'll make that change in my forthcoming patch. Just rebasing some things.

--000000000000ae4c4b064c9c69ef
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 2:56=E2=80=AFPM Sami Imseih &lt;<a href=3D"mailto:samimseih@gmail.c=
om">samimseih@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex">&gt;&gt; nathan<br>
&gt;<br>
&gt;<br>
&gt; You&#39;re both right. Currently, we fetch extended stats one at a tim=
e, thus there&#39;s no _immediate_ need to do so.<br>
&gt;<br>
&gt; But &quot;why wait until there is a crisis&quot; is solid reasoning an=
d for that I had already coded up the change.<br>
&gt;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<br>
&gt; as that was something that we at least briefly thought we&#39;d need f=
or importing expression statistics. However the existing query<br>
&gt; uses a SELECT unnest(a), unnest(b) pattern in it, and WITH ORDINALITY =
is not allowed, and the workarounds I found seemed a<br>
&gt; 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<br>
&gt; I&#39;ll happily inflict that tortured SQL on y&#39;all.<br>
<br>
Can we add the tableid=C2=A0 for now (see 0003) and follow-up with another<=
br>
thread with the sql changes to pg_dump?<br></blockquote><div><br></div><div=
>Presently, I don&#39;t think we make any changes to pg_dump, unless Nathan=
 feels strongly that we should. If and when the need for oid-based fetching=
 of extended stats becomes necessary, we&#39;ll at least have a couple vers=
ions where the catalog already had the oids handy.</div><div></div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I also corrected v2-0001. The docs were still referencing &quot;starlid&quo=
t;<br>
instead of &quot;tableid&quot;<br></blockquote><div><br></div><div>I&#39;ll=
 make that change in my forthcoming patch. Just rebasing some things.</div>=
<div><br></div><br></div></div>

--000000000000ae4c4b064c9c69ef--