Re: Add starelid, attnum to pg_stats and leverage this in pg_dump

On Mon, Mar 9, 2026 at 2:56 PM Sami Imseih <samimseih@gmail.com> wrote:

> >> 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.
>
> 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.