> > I believe you are referring to Tom's statement that "it'll be a > serious, serious error for [stats] not to be SECTION_DATA". The > statement is somewhat softened by the sentence that follows, and > slightly more by [2]. But it's pretty clear that SECTION_POST_DATA is, > at best, an implementation comprosmise. > > The reason we need to put some stats in SECTION_POST_DATA is because of > the hack to resolve MVs that depend on primary keys by moving the MV > into SECTION_POST_DATA. (An MV can depend on a primary key when the > query has a GROUP BY that relies on functional dependencies to be > valid.) That's a fairly marginal case, and one we might be able to > resolve a better way in the future, so I don't think that should drive > the design. >
I understand the benefits of having statistics on the underlying tables could aid the performance of the queries that populate the materialized views. What I struggle to understand is how that purpose isn't served better by statistics being in SECTION_NONE like COMMENTs are, so that they are imported immediately after the object that they reference. > > Reagrding [2] and [3], we might need to reconsider the behavior of the > --data-only option. I asked for the v38 behavior out of a sense of > consistency and completeness (the ability to express whatever > combination of things the user might want). But re-reading those > messages, we might want --data-only to include the stats? I think there's going to be some friction in the user's shift from thinking that they did want only data to realizing that they actually didn't want schema.
