Importing Extended Statistics

From: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Importing Extended Statistics
Date: 2024-04-12 17:36:28
Message-ID: CADkLM=fap51HUrxqqiK8K6PKJ-At+JKXZ0aH6eqBveEO3Dnxyw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I'm creating this new thread separate from the existing Statistics
Export/Import thread to keep the original thread focused on that patch.

Assuming that the function signature for pg_set_attribute_stats() remains
the same (regclass, attname, inherited, version, ...stats...), how would we
design the function signature for pg_set_extended_stats()?

Currently, the variant arguments in pg_set_attribute_stats are mapping
attribute names from pg_stats onto parameter names in the function, so a
call looks like this:

SELECT pg_set_attribute_stats('public.foo'::regclass, 'foo_id', false,
17000,
'null_frac', 0.4::real,
'avg_width', 20::integer,
'n_distinct, ', 100::real,
...);

And that works, because there's a 1:1 mapping of attribute names to param
names in the pairs of variants.

However, that won't work for extended stats, as it has 2 mappings:

* 1 set of stats from pg_stats_ext
* N sets of stats from pg_stats_ext_exprs, one per expression contained in
the statistics object definition.

My first attempt at making this possible is to have section markers. The
variant arguments would be matched against column names in pg_stats_ext
until the parameter 'expression' is encountered, at which point it would
begin matching parameters from pg_stats_ext_exprs to parameters for the
first expression. Any subsequent use of 'expression' would move the
matching to the next expression.

This method places a burden on the caller to get all of the pg_stats_ext
values specified before any expression values. It also places a burden on
the reader that they have to count the number of times they see
'expression' used as a parameter, but it otherwise allows 1 variant list to
serve two purposes.

Thoughts?

Browse pgsql-hackers by date

  From Date Subject
Next Message Melanie Plageman 2024-04-12 17:48:30 Re: Table AM Interface Enhancements
Previous Message Imseih (AWS), Sami 2024-04-12 17:27:40 Re: allow changing autovacuum_max_workers without restarting