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>
In-Reply-To: <aathGcXAIpiUSP_s@nathan>
From: Sami Imseih <samimseih@gmail.com>
Date: Mon, 9 Mar 2026 10:44:58 -0500
Message-ID: 
 <CAA5RZ0vCuDDd6-H00aabjLri0yO_AMJQ4Lb4017pepqU5WNyFg@mail.gmail.com>
Subject: Re: Add starelid, attnum to pg_stats and leverage this in pg_dump
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Corey Huinker <corey.huinker@gmail.com>,
 pgsql-hackers@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CAA5RZ0vCuDDd6-H00aabjLri0yO_AMJQ4Lb4017pepqU5WNyFg%40mail.gmail.com>
Precedence: bulk

> Oh, a question I forgot to ask: why wouldn't we do the same thing for
> pg_stats_ext and pg_stats_ext_exprs?

The primary purpose of adding the relid is to optimize queries on
pg_statistics in pg_dump.

+ *
* The redundant filter clause on s.tablename = ANY(...) seems
* sufficient to convince the planner to use
* pg_class_relname_nsp_index, which avoids a full scan of pg_stats.
- * This may not work for all versions.
+ * This seems to work for all version prior to v19, after which we
+ * will use the starelid, which is simpler.

pg_stats_ext and pg_stats_ext_expr do not have the same concern.

If we do add relid there, it will be for consistency only.

--
Sami Imseih
Amazon Web Services (AWS)