Re: Statistics Import and Export

>
> 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.