Re: Statistics Import and Export

On Mon, Jan 27, 2025 at 11:09 AM Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
wrote:

> On Mon, Jan 27, 2025 at 9:05 AM jian he <jian(dot)universality(at)gmail(dot)com>
> wrote:
>
>> On Tue, Jan 21, 2025 at 7:31 AM Jeff Davis <pgsql(at)j-davis(dot)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.
>
>
>>
>> Tomas Vondra also mentioned this on [1]
>> [1]
>> https://www.postgresql.org/message-id/bf724b21-914a-4497-84e3-49944f9776f6%40enterprisedb.com
>>
>> > * 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.
>

Seems I also replied only to Micahel with the v45 patch.

And here's an update to the pg_dump code itself. This currently has failing
TAP tests for statistics in the custom and dir formats, but is working
otherwise.