Re: Fix --missing-stats-only false positive for partitioned expression indexes

From: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Baji Shaik <baji(dot)pgdev(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Fix --missing-stats-only false positive for partitioned expression indexes
Date: 2026-06-16 18:28:20
Message-ID: CADkLM=fD90umSd5f8yooQ4QESrzPpAunn9_Bb5Ap0u+0AyfFuA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jun 16, 2026 at 1:54 PM Nathan Bossart <nathandbossart(at)gmail(dot)com>
wrote:

> On Tue, Jun 16, 2026 at 12:51:28PM -0500, Nathan Bossart wrote:
> > On Tue, Jun 16, 2026 at 01:25:27PM -0400, Corey Huinker wrote:
> >> I know this is a corner-case of a corner-case, but if " AND
> s.stainherit
> >> OPERATOR(pg_catalog.=) p.inherited", we might then get a false negative
> >> from a situation like this:
> >>
> >> t2 inherits t1
> >> t1 has ineritance stats but somehow not regular stats
> >> t2 dis-inherits from t1, t1 is no longer p.inherited = true, but
> inherited
> >> stats remain
> >>
> >> vacuumdb goes looking for matches, sees that t1 is p.inherited = false,
> >> find the old inherited stat row, not realizing it should have been
> looking
> >> for a non-inherits row.
> >
> > Since p.inherited is set based on the relkind, it could only change if
> the
> > table was converted from partitioned to not partitioned. IIRC that's not
> > currently possible.
>
> (Also, expression index stats are documented as always having stainherit =
> false...)

Oh good. I like it when things are not problems.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Corey Huinker 2026-06-16 19:11:45 Re: use of SPI by postgresImportForeignStatistics
Previous Message Bruce Momjian 2026-06-16 18:14:35 Re: First draft of PG 19 release notes