Re: Add expressions to pg_restore_extended_stats()
| От | Corey Huinker |
|---|---|
| Тема | Re: Add expressions to pg_restore_extended_stats() |
| Дата | |
| Msg-id | CADkLM=ddBau8AFeQ3OHCWKZXFrB=Y-5dLkZnNdAOtbr1Qa2rGg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Add expressions to pg_restore_extended_stats() (Michael Paquier <michael@paquier.xyz>) |
| Ответы |
Re: Add expressions to pg_restore_extended_stats()
|
| Список | pgsql-hackers |
v5-0001 still requires a lot of changes at quick glance, as of:
- Some diffs not required in some comment blocks.
Kept the s/stxdexprs/stxdexpr, as that is the correct column name, the other changes are reverted.
- Regression test diffs show up for cases where WARNING messages are
changed, but should not. See for example the MCV checks.
reverted.
- A couple of newly-introduced error strings use wordings that are not
project-style, as of the "malformed expressions", there is also a
"malformed expr expression".
Updated all error messages. I tried to add in expr/name location via the context stack, but those callback are only called for ERRORs and higher. So, I did what I could with errhint()s.
+ * #include "catalog/pg_collation_d.h" if (typid == TSVECTOROID) stacoll =
+ * DEFAULT_COLLATION_OID;
We did need to do this, and it has been implemented, along with a new test on a new statistics object which has a to_tsvector(text_column) expression in it.
+ *
+ * The multirange step-down may also need to happen here too.
+ */
Multirange types in expressions generate exactly 2 stakinds: STATISTIC_KIND_RANGE_LENGTH_HISTOGRAM (6) and STATISTIC_KIND_BOUNDS_HISTOGRAM (7), neither of which are exposed by pg_stats_ext_exprs, so they can't be imported, so at present there is nothing to test and we can skip the multirange step-down for now. Inspecting the stavalues1 and stavalues2 values in pg_statistic_ext_data gives me the impression that we don't need the step-down, as the values appear to be regular range types, and the exiting function to get the element type should suffice.
We should probably modify the view to include these new-ish statistic kinds, but that's for another patch.
Now that we have an agreement about the format of the input data and
how it maps with the assumptions of the stats computations in ANALYZE,
the hardest part is IMO done. However, could you clean up things?
This patch is not really in an acceptable shape: it has a bunch of
avoidable errors and it requires a lot of tweaks before even being
looked at more closely.
Moving to the found[] and vals[] arrays cleans up the logic a lot, I think, which is all the more important now that we keep building the expressions after components of that statistic fail.
Вложения
В списке pgsql-hackers по дате отправления: