Re: Support NOT VALID / VALIDATE constraint options for named NOT NULL constraints - Mailing list pgsql-hackers

From Rushabh Lathia
Subject Re: Support NOT VALID / VALIDATE constraint options for named NOT NULL constraints
Date
Msg-id CAGPqQf2MYSQAdJ11v5b3hqdsOCw=LO_EgbMXwJ41S-+qxA6tZg@mail.gmail.com
Whole thread Raw
In response to Re: Support NOT VALID / VALIDATE constraint options for named NOT NULL constraints  (Peter Eisentraut <peter@eisentraut.org>)
List pgsql-hackers


On Thu, Apr 3, 2025 at 8:33 PM Peter Eisentraut <peter@eisentraut.org> wrote:
On 03.04.25 10:07, Alvaro Herrera wrote:
> The new flag is there for quick access by get_relation_info.  We could
> easily not have it otherwise, because clients don't need it, but its
> lack would probably make planning measurably slower because it'd have to
> do syscache access for every single not-null constraint to figure out if
> it's valid or not.

In the v6 patch, you are adding a attnullability field to the
CompactAttribute in the tuple descriptor and use that in
get_relation_info().  That seems like the right approach, because then
you're doing all that preprocessing about which constraint is active in
the relcache.  So I don't see where the extra pg_attribute field
attnotnullvalid is getting used.'

attnotnullvalid is getting used to populate the CompatAttribute (populate_compact_attribute_internal).
The primary reason for adding a new field to pg_attribute is to avoid the need for an additional scan
of pg_constraint when populating CompatAttribute, as this extra scan introduces performance overhead
while retrieving catalog information for a relation.



--
Rushabh Lathia

pgsql-hackers by date:

Previous
From: Dmitrii Bondar
Date:
Subject: Re: [fixed] Trigger test
Next
From: Konstantin Knizhnik
Date:
Subject: Re: New criteria for autovacuum