Re: pg_restore handles extended statistics inconsistently with statistics data

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
Cc: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>
Subject: Re: pg_restore handles extended statistics inconsistently with statistics data
Date: 2026-06-16 06:59:29
Message-ID: ajD0UZJFeO68ox-C@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chao Li 2026-06-16 07:20:19 Re: pg_restore handles extended statistics inconsistently with statistics data
Previous Message Shlok Kyal 2026-06-16 06:39:47 Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication