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-30, Manu wrote:

> 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.

I think the difficult question here is how are we going to evaluate the
condition on the tuple. We absolutely can't run the full executor, so
there needs to be some way to limit what we're willing to do, and
finding a way to do it without calling anything other than a very
limited set of functions -- something like "is OID different than
0" has got to be enough. I have no idea how to make that work and still
have a representation of the restriction in the system catalogs for the
catalog rows themselves.

But yeah, let's discuss in a new thread if you can figure out an answer
to that.

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/