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) - Mailing list pgsql-hackers

From Álvaro Herrera
Subject 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)
Date
Msg-id arvPP0KhJvyf7sLA@alvherre.pgsql
Whole thread
In response to 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)  (Manu <manuelreyesbravo@gmail.com>)
Responses 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)
List pgsql-hackers
On 2026-Sep-29, Manu wrote:

> I'd be glad to put a patch together once there's a sense of the
> preferred direction.  The partial index is the smallest change, but
> whether a new catalog index is the way to go, versus the pg_depend
> lookup or the trigger-based early exit, is more your and the
> committers' call.  Happy to test any of them against the reproducer.

I vaguely recall looking into adding such an index, and finding out that
we don't support partial indexes on catalogs.  Is that doable in some
clean way nowadays?  (Or maybe the index worked fine, and what failed
was adding a syscache on top of it?  Not sure.)

I first mentioned this in 2019 ...
https://postgr.es/m/20190318220223.GA15196@alvherre.pgsql

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"Drawing in linguistics, Makefiles are more like proto languages, where you might
identify a few fragments but otherwise never be sure if the speaker asked for
a proto sandwich or all your money."  (grmnsftphr, https://lwn.net/Articles/1093871/)



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Costing for parallel scans with few/single row produced in the outer side
Next
From: Tom Lane
Date:
Subject: Re: remove_useless_joins vs. bug #19560