Thanks a lot for the detailed and thoughtful feedback. I want to confirm my understanding of the points raised and how I plan to align the work going forward.
On the implementation details raised by Ilia: I agree that the current flag definition and placement need correction. The MISSING_STATS option must use a unique flag value, and the check should be performed only after the standard relation validation, privilege checks, and existing skip conditions in analyze_rel(). I will fix both and verify the behavior with assertions enabled.
Regarding behavior and scope, I understand the concern that the current v3 implementation does not exactly match vacuumdb --missing-stats-only semantics. My intent was not to claim behavioral equivalence, but to expose a server-side ANALYZE option that identifies relations requiring statistics collection. I agree that this distinction needs to be made clearer.
The suggestion to reuse existing ANALYZE internals, in particular examine_attribute(), makes sense. Leveraging that logic to determine whether analyzable attributes lack statistics should align the implementation more closely with core ANALYZE behavior and avoid re-defining missing-stats rules independently.[Thanks Sami for teaching me this as i am an new contributor:) ]
On vacuumdb integration: I agree that this patch should focus only on defining server-side ANALYZE semantics. As noted, vacuumdb is a client tool that must handle multiple server versions, and the definition of “missing stats” itself is evolving (especially for extended and expression statistics). Adapting vacuumdb to use ANALYZE(MISSING_STATS_ONLY) can be considered as follow-up work once the server-side behavior is finalized.
Finally, I agree that the option name should be MISSING_STATS_ONLY for clarity and consistency with vacuumdb.
Thanks again for the guidance — it has been very helpful in understanding the expected direction and design constraints. I will post an updated patch addressing the above points.
