public inbox for [email protected]
help / color / mirror / Atom feedFrom: Corey Huinker <[email protected]>
To: Sami Imseih <[email protected]>
Cc: Nathan Bossart <[email protected]>
Cc: [email protected]
Subject: Re: Add starelid, attnum to pg_stats and leverage this in pg_dump
Date: Mon, 9 Mar 2026 15:28:40 -0400
Message-ID: <CADkLM=cYLk7bi3QVMBGWsFEzNfpqyV1Es3tWCwfERS88MdULWQ@mail.gmail.com> (raw)
In-Reply-To: <CAA5RZ0s674FM8vcEqr+DUVjWOpYSPS-rG8uANdJKEnSyo+tObA@mail.gmail.com>
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>
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.
view thread (36+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: Add starelid, attnum to pg_stats and leverage this in pg_dump
In-Reply-To: <CADkLM=cYLk7bi3QVMBGWsFEzNfpqyV1Es3tWCwfERS88MdULWQ@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox