On Mon, Mar 9, 2026 at 2:56 PM Sami Imseih <[email protected]> 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.
