Re: Statistics Import and Export

From: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
To: jian he <jian(dot)universality(at)gmail(dot)com>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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>, alvherre(at)alvh(dot)no-ip(dot)org
Subject: Re: Statistics Import and Export
Date: 2024-09-17 09:02:49
Message-ID: CADkLM=eErgzn7ECDpwFcptJKOk9SxZEk5Pot4d94eVTZsvj3gw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
> Please check my attached changes.
> also see the attached cf-bot commit message.
>
> 1. make sure these three functions: 'pg_set_relation_stats',
> 'pg_restore_relation_stats','pg_clear_relation_stats' proisstrict to true.
> because in
> pg_class catalog, these three attributes (relpages, reltuples,
> relallvisible) is
> marked as not null. updating it to null will violate these constraints.
> tom also mention this at [
>

Things have changed a bit since then, and the purpose of the functions has
changed, so the considerations are now different. The function signature
could change in the future as new pg_class stats are added, and it might
not still be strict.

>
> 2.refactor relation_statistics_update. first sanity check first argument
> ("relation").
> not all kinds of relation can pass on
> relation_statistics_update, for example view. so do the sanity check.
> also do sanity check for the remaining 3 arguments.
> if not ok, ereport(elevel...), return false immediately.
>

I have added checks for non-stats-having pg_class types.

> 3.add some tests for partitioned table, view, and materialized view.
>

We can do that, but they're all just relations, the underlying mechanism is
the same. All we'd be testing is that there is no check actively preventing
statistics import for those types.

>
> 4. minor sanity check output of "attnum = get_attnum(reloid,
> NameStr(*attname));"
>

While this check makes sense, it falls into the same category as the sanity
checks mentioned in #2. Not against it, but others have found value in just
allowing these things.

>
> 5.
> create table t(a int, b int);
> alter table t drop column b;
> SELECT pg_catalog.pg_set_attribute_stats(
> relation => 't'::regclass,
> attname => 'b'::name,
> inherited => false::boolean,
> null_frac => 0.1::real,
> avg_width => 2::integer,
> n_distinct => 0.3::real);
>
> ERROR: attribute 0 of relation with OID 34316 does not exist
> The error message is not good, i think.
> Also, in this case, I think we may need soft errors.
> instead of returning ERROR, make it return FALSE would be more ok.
>

I agree that we can extract the name of the oid for a better error message.
Added.

The ERROR vs WARNING debate is ongoing.

>
> 6. there are no "inherited => true::boolean,"
> tests for pg_set_attribute_stats.
> aslo there are no partitioned table related tests on stats_import.sql.
> I think we should add some.
>

There aren't any, but that does get tested in the pg_upgrade test.

> 7. the doc output, functions-admin.html, there are 4 same warnings.
> Maybe one is enough?
>

Perhaps, if we had a good place to put that unified message.

>
> 8. lock_check_privileges function issue.
> ------------------------------------------------
> --asume there is a superuser jian
> create role alice NOSUPERUSER LOGIN;
> create role bob NOSUPERUSER LOGIN;
> create role carol NOSUPERUSER LOGIN;
> alter database test owner to alice
> GRANT CONNECT, CREATE on database test to bob;
> \c test bob
> create schema one;
> create table one.t(a int);
> create table one.t1(a int);
> set session AUTHORIZATION; --switch to superuser.
> alter table one.t1 owner to carol;
> \c test alice
> --now current database owner alice cannot do ANYTHING WITH table one.t1,
> like ANALYZE, SELECT, INSERT, MAINTAIN etc.
>

Interesting.

I've taken most of Jeff's work, reincorporated it into roughly the same
patch structure as before, and am posting it now.

Highlights:

- import_stats.c is broken up into stats_utils.c, relation_stats.c, and
attribute_stats.c. This is done in light of the existence of
extended_stats.c, and the fact that we will have to eventually add stats
import to extended stats.
- Many of Jian's suggestions were accepted.
- Reorganized test structure to leverage pg_clear_* functions as a way to
cleanse the stats palette between pg_set* function tests and pg_restore*
function tests.
- Rebased up to 95d6e9af07d2e5af2fdd272e72b5b552bad3ea0a on master, which
incorporates Nathan's recent work on pg_upgrade.

Attachment Content-Type Size
v29-0003-Add-relkind-check-to-stats_lock_check_privileges.patch text/x-patch 3.3 KB
v29-0001-Create-statistics-manipulation-utility-functions.patch text/x-patch 7.9 KB
v29-0005-Create-functions-pg_restore_relation_stats-pg_re.patch text/x-patch 90.5 KB
v29-0002-Create-functions-pg_set_relation_stats-pg_clear_.patch text/x-patch 19.4 KB
v29-0004-Create-functions-pg_set_attribute_stats-pg_clear.patch text/x-patch 88.1 KB
v29-0007-Enable-dumping-of-table-index-stats-in-pg_dump.patch text/x-patch 33.9 KB
v29-0006-Add-derivative-flags-dumpSchema-dumpData.patch text/x-patch 17.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2024-09-17 09:05:51 Re: Using per-transaction memory contexts for storing decoded tuples
Previous Message Alexander Lakhin 2024-09-17 09:00:00 Re: [HACKERS] make async slave to wait for lsn to be replayed