Re: Fix --missing-stats-only false positive for partitioned expression indexes - Mailing list pgsql-hackers

From Corey Huinker
Subject Re: Fix --missing-stats-only false positive for partitioned expression indexes
Date
Msg-id CADkLM=fD90umSd5f8yooQ4QESrzPpAunn9_Bb5Ap0u+0AyfFuA@mail.gmail.com
Whole thread
In response to Re: Fix --missing-stats-only false positive for partitioned expression indexes  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: Fix --missing-stats-only false positive for partitioned expression indexes
List pgsql-hackers


On Tue, Jun 16, 2026 at 1:54 PM Nathan Bossart <nathandbossart@gmail.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.

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: First draft of PG 19 release notes
Next
From: Corey Huinker
Date:
Subject: Re: use of SPI by postgresImportForeignStatistics