Re: ATTACH PARTITION cost grows linearly with pg_constraint size (seqscan in CloneFkReferenced), much worse since not-null constraints are in pg_constraint (PG 18)

On 2026-Sep-29, Álvaro Herrera wrote:

> Makes sense. Please create a commitfest entry for this, if there
> isn't one already.

Done -- it's CF 7365 in PG20-3.

> I think we should explore the idea of adding support for partial
> indexes on catalogs, though. Having an index 90% populated by
> useless entries doesn't sound like the best use of resources.
> Perhaps we could also use such functionality on
> ConstraintRelidTypidNameIndexId, splitting that into two indexes,
> one for constraints on types and another for indexes on relations,
> and avoid having to store InvalidOid on the other column.
> This doesn't have to delay this patch, however.

I'd like to take that up. I spent some time mapping what stands in
the way today, and it comes down to two places:

- The bootstrap index grammar (Boot_DeclareIndexStmt in
bootparse.y) has no WHERE production, so a predicate declared in
the catalog headers reaches genbki but initdb cannot parse it.

- CatalogIndexInsert() asserts ii_Predicate == NIL and never
evaluates a predicate, so even a built index would be maintained
for every row.

The engine side (index_create) already carries ii_Predicate, so the
work looks contained to those two spots rather than the access method
layer.

If that reading matches yours, I can start a separate thread with a
first sketch, using confrelid and the ConstraintRelidTypidNameIndexId
split you mention as the two motivating cases. Happy to hear if
you'd shape it differently.

Manu