| From: | Sami Imseih <samimseih(at)gmail(dot)com> |
|---|---|
| To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
| Cc: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Add starelid, attnum to pg_stats and leverage this in pg_dump |
| Date: | 2026-03-09 15:44:58 |
| Message-ID: | CAA5RZ0vCuDDd6-H00aabjLri0yO_AMJQ4Lb4017pepqU5WNyFg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> 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)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alena Rybakina | 2026-03-09 15:46:14 | Re: Vacuum statistics |
| Previous Message | Heikki Linnakangas | 2026-03-09 15:41:57 | Re: pg_combinebackup: incorrect size of VM fork after combine |