Re: pg_restore handles extended statistics inconsistently with statistics data

> On Jun 12, 2026, at 14:56, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
>
>
>
>> On Jun 12, 2026, at 14:05, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>>
>> On Thu, Jun 11, 2026 at 11:31:26AM +0800, Chao Li wrote:
>>> I tried the same test against 1ea44d7ddfb, the immediate predecessor
>>> of c32fb29e9. pg_dump dumped relation stats and attribute stats,
>>> while pg_restore restored nothing. So the asymmetric behavior for
>>> stats already existed. c32fb29e9 then added extended stats to both
>>> pg_dump and pg_restore, but the new EXTENDED STATISTICS DATA entries
>>> are handled differently from STATISTICS DATA during selective
>>> pg_restore, making the inconsistency visible.
>>>
>>> The asymmetric behavior was not introduced by c32fb29e9, so I think
>>> we probably should not change that for v19. If it's confirmed that
>>> this needs to be fixed and nobody else plans to work on it, I would
>>> be happy to add it to my TODO list for v20.
>>
>> FWIW, I'm going to disagree with your argument, as I find the behavior
>> of v18 really weird.
>
> Yeah, I had the same feeling.
>
>> I would have assumed that the pg_restore
>> --statistics-only should restore all the stats in the schema without
>> the objects in the schema, relation and attribute stats (+extended,
>> only applies with v19), for all the objects in the schema. If you
>> want only the schema definition and not the objects, we already have
>> -s for the job.
>>
>> In your example, the dump in custom format with --statistics looks
>> right to me: object definitions and stats. pg_dump -Fc
>> --statistics-only also looks right: only the stats, no objects. The
>> restore part is bumpy.
>>
>> So I'd like to think that the behavior of the relation and attribute
>> stats is wrong in v18 and v19, and that the behavior of extended stats
>> is actually the right one in v19. Why should custom and plain formats
>> differ when filtering with a --schema and --statistics-only?
>>
>> At the end, it seems to me that the right thing to do is the patch
>> attached, to-be-backpatched down to v18.
>
> Totally agreed. Making pg_dump and pg_restore behave consistently also feels like the right direction to me.
>
> I was just not sure if we should do that now or for v20, as we are supposed to fix v19-only issues at the current stage. I didn’t verify that on v18.
>
>> check-world passes with this
>> patch, so we have never tested really this path, I guess? I could see
>> myself adding a scenario in 003, at least.
>>
>> Jeff or Corey, could you comment please?
>> --
>> Michael
>> <0001-Fix-pg_restore-with-schema-and-statistics-only.patch>
>

If the fix direction is to make pg_restore behave consistently with pg_dump, then I think Michael's change is correct.

I tried to add a test for this. Without the fix, the test fails as below:
```
# +++ tap check in src/bin/pg_dump +++
t/002_pg_dump.pl .. 9710/?
# Failed test 'statistics_only_dump_test_schema_restore: should dump relstats_on_unanalyzed_tables'
# at t/002_pg_dump.pl line 5339.
# '--
```

See the attached v2 for details.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/