| From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
| Cc: | jian he <jian(dot)universality(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Support NOT VALID / VALIDATE constraint options for named NOT NULL constraints |
| Date: | 2025-04-03 15:03:34 |
| Message-ID: | f88ddb82-1d6d-459d-8b9f-e75f07977ec3@eisentraut.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2025-04-03 15:17:08 | Re: Using read stream in autoprewarm |
| Previous Message | Bernd Helmle | 2025-04-03 15:00:43 | Re: [PATCH] Add sortsupport for range types and btree_gist |