Re: Statistics Import and Export

On Tue, Feb 25, 2025 at 1:22 PM Jeff Davis <pgsql(at)j-davis(dot)com> wrote:

> On Mon, 2025-02-24 at 12:50 -0500, Tom Lane wrote:
> > Also, while working on the attached, I couldn't help forming the
> > opinion that we'd be better off to nuke pg_set_attribute_stats()
> > from orbit and require people to use pg_restore_attribute_stats().
>
> Attached a patch to do so. The docs and tests required substantial
> rework, but I think it's for the better now that we aren't trying to do
> in-place updates.
>
> Regards,
> Jeff Davis
>
>
All the C code changes make sense to me. Though as an aside, we're going to
run into the parameter-ordering problem when it comes to
pg_clear_attribute_stats, but that's a (read: my) problem for a later patch.

Documentation:

+ The currently-supported relation statistics are
+ <literal>relpages</literal> with a value of type
+ <type>integer</type>, <literal>reltuples</literal> with a value of
+ type <type>real</type>, and <literal>relallvisible</literal> with
a
+ value of type <type>integer</type>.

Could we make this a bullet-list? Same for the required attribute stats and
optional attribute stats. I think it would be more eye-catching and useful
to people skimming to recall the name of a parameter, which is probably
what most people will do after they've read it once to get the core
concepts.

Question:

Do we want to re-compact the oids we consumed in pg_proc.dat?

Test cases:

We're ripping out a lot of regression tests here. Some of them obviously
have no possible pg_restore_* analogs, such as explicitly set NULL values
vs omitting the param entirely, but some others may not, especially the
ones that test required arg-pairs.

Specifically missing are:

* regclass not found
* attribute is system column
* scalars can't have mcelem
* mcelem / mcelem freqs mismatch (parts 1 and 2)
* scalars can't have elem_count_histogram
* cannot set most_common_elems for range type

I'm less worried about all the tests of successful import calls, as the
pg_upgrade TAP tests kick those tires pretty well.

I'm also ok with losing the copies from test to test_clone, those are also
covered well by the TAP tests.

I'd feel better if we adapted the above tests from set-tests to
restore-tests, as the TAP suite doesn't really cover intentionally bad
stats.