Re: Statistics Import and Export

From: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
To: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeff Davis <pgsql(at)j-davis(dot)com>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Stephen Frost <sfrost(at)snowman(dot)net>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
Subject: Re: Statistics Import and Export
Date: 2024-04-24 10:18:30
Message-ID: CADkLM=fwL5uFsCzEtmU_5pSFf67_23WpJTwMU1cMe3wZ5BdhRQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
> I've heard of use cases where dumping stats without data would help
> with production database planner debugging on a non-prod system.
>

So far, I'm seeing these use cases:

1. Binary upgrade. (schema: on, data: off, stats: on)
2. Dump to file/dir and restore elsewhere. (schema: on, data: on, stats: on)
3. Dump stats for one or more objects, either to directly apply those stats
to a remote database, or to allow a developer to edit/experiment with those
stats. (schema: off, data: off, stats: on)
4. restore situations where stats are not wanted and/or not trusted
(whatever: on, stats: off)

Case #1 is handled via pg_upgrade and special case flags in pg_dump.
Case #2 uses the default pg_dump options, so that's covered.
Case #3 would require a --statistics-only option mutually exclusive with
--data-only and --schema-only. Alternatively, I could reanimate the script
pg_export_statistics, but we'd end up duplicating a lot of filtering
options that pg_dump already has solved. Similarly, we may want server-side
functions that generate the statements for us (pg_get_*_stats paired with
each pg_set_*_stats)
Case #4 is handled via --no-statistics.

Attached is v19, which attempts to put table stats in SECTION_DATA and
matview/index stats in SECTION_POST_DATA. It's still failing one TAP test
(004_pg_dump_parallel: parallel restore as inserts). I'm still unclear as
to why using SECTION_NONE is a bad idea, but I'm willing to go along with
DATA/POST_DATA, assuming we can make it work.

Attachment Content-Type Size
v19-0001-Create-pg_set_relation_stats-pg_set_attribute_st.patch text/x-patch 109.9 KB
v19-0002-Enable-dumping-of-table-index-stats-in-pg_dump.patch text/x-patch 23.9 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2024-04-24 10:19:35 Re: Race condition in FetchTableStates() breaks synchronization of subscription tables
Previous Message Peter Eisentraut 2024-04-24 10:12:28 Re: Why does pgindent's README say to download typedefs.list from the buildfarm?