Re: pg_restore handles extended statistics inconsistently with statistics data - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: pg_restore handles extended statistics inconsistently with statistics data
Date
Msg-id ajD0UZJFeO68ox-C@paquier.xyz
Whole thread
In response to Re: pg_restore handles extended statistics inconsistently with statistics data  (Chao Li <li.evan.chao@gmail.com>)
Responses Re: pg_restore handles extended statistics inconsistently with statistics data
List pgsql-hackers
On Tue, Jun 16, 2026 at 02:36:21PM +0800, Chao Li wrote:
> I think the dependency-based matching is better, but what happens if
> the archive is created with --statistics-only? In that case, the
> statistics entries still have dependencies, but the referenced
> parent TOC entries are not present in the archive. See the attached
> test script. It creates the archive with --statistics-only, with the
> new patch, neither table nor index stats are restored:

I can see your argument in that HEAD can improve the detection in what
gets restored if the dumps only include the stats data, but I don't
really buy that this is a use case interesting to support: one can
also dump the data with the index definition and then filter back the
contents when restoring using --index.  So at the end having a tighter
check at the restore is more appealing to me, because it leads to a
more predictible result, like in the scenario I have posted upthread
when a schema has the idea to include tables and indexes with the same
names (unlikely, okay, still).  Or in short, don't do that.

For the case of upgrades one or the other does not really matter,
pg_upgrade treats all the objects in full.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Shlok Kyal
Date:
Subject: Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication
Next
From: Chao Li
Date:
Subject: Re: pg_restore handles extended statistics inconsistently with statistics data