On Tue, Jan 21, 2025 at 7:31 AM Jeff Davis <pgsql@j-davis.com> wrote: > > On Mon, 2025-01-20 at 16:45 -0500, Corey Huinker wrote: > > > > 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. > > Tom, you expressed the strongest opinions on this point, can you expand > a bit? > > If I understand correctly: > > * We strongly want stats to be exported by default[1]. > > * Adding a SECTION_STATS could work, but would be non-trivial and might > break expectations about the set of sections available[2]. > > * SECTION_NONE doesn't seem right. There would be no way to get the > stats using --section. Also, if there is no section boundary for the > stats, then couldn't they appear in a surprising order? > > * I'm not sure about placing stats in SECTION_POST_DATA. That doesn't > seem terrible to me, but not great either. >
index is on SECTION_POST_DATA. To dump all the statistics, we have to go through SECTION_POST_DATA. place it there would be more convenient.
That would be the simpler solution, but those statistics may come in handy for refreshing mviews, so some may want table stats to stay in SECTION_DATA.
> * I'm also not 100% sure about the flags. The default should dump the > stats, of course. And I like the idea of allowing any combination of > schema, data and stats to be exported. But that leaves a wrinkle for -- > data-only, which (as of v38) does not dump stats, because stats are a > third kind of thing. Perhaps stats should be expressed as a subtype of > data somehow, but I'm not sure exactly how. > if we have --data-only, --schema-only, --statistics-only, three options, then --data-only also dump statistics would be unintuitive?
Yeah, I think the codebase and the user flags both have confusing bits where the not-wanting of one type of thing was specified by only-wanting the other thing, and those choices fall apart when the binary becomes trinary.
