On Tue, 2024-03-19 at 05:16 -0400, Corey Huinker wrote:
> v11 attached.
Thank you.
Comments on 0001:
This test:
+SELECT
+ format('SELECT pg_catalog.pg_set_attribute_stats( '
...
seems misplaced. It's generating SQL that can be used to restore or
copy the stats -- that seems like the job of pg_dump, and shouldn't be
tested within the plain SQL regression tests.
And can the other tests use pg_stats rather than pg_statistic?
The function signature for pg_set_attribute_stats could be more
friendly -- how about there are a few required parameters, and then it
only sets the stats that are provided and the other ones are either
left to the existing value or get some reasonable default?
Make sure all error paths ReleaseSysCache().
Why are you calling checkCanModifyRelation() twice?
I'm confused about when the function should return false and when it
should throw an error. I'm inclined to think the return type should be
void and all failures should be reported as ERROR.
replaces[] is initialized to {true}, which means only the first element
is initialized to true. Try following the pattern in AlterDatabase (or
similar) which reads the catalog tuple first, then updates a few fields
selectively, setting the corresponding element of replaces[] along the
way.
The test also sets the most_common_freqs in an ascending order, which
is weird.
Relatedly, I got worried recently about the idea of plain users
updating statistics. In theory, that should be fine, and the planner
should be robust to whatever pg_statistic contains; but in practice
there's some risk of mischief there until everyone understands that the
contents of pg_stats should not be trusted. Fortunately I didn't find
any planner crashes or even errors after a brief test.
One thing we can do is some extra validation for consistency, like
checking that the arrays are properly sorted, check for negative
numbers in the wrong place, or fractions larger than 1.0, etc.
Regards,
Jeff Davis