Re: not null constraints, again - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: not null constraints, again
Date
Msg-id 202410041308.umwqeozh2zir@alvherre.pgsql
Whole thread Raw
In response to Re: not null constraints, again  (jian he <jian.universality@gmail.com>)
List pgsql-hackers
On 2024-Oct-03, jian he wrote:

> I thought SearchSysCacheCopyAttNum is expensive.
> Relation->rd_att is enough for checking attnotnull.
> 
> What do you think of the following refactoring of set_attnotnull?

Eh, sure, why not.  I mean, I expect that this is going to be barely
noticeable performance-wise, but I don't see a reason not to do it this
way.


The new code in transformIndexConstraint() I added to verify NO INHERIT
for columns in the PK[1] is likely to have a more noticeable impact: we
have to scan the whole cxt->nnconstraints list for each column of the
PK, and strcmp() the column names in order to find matches.  I expect
this this to be slow (and affect everybody) but I don't see any other
reasonable way to do it.  A possibility is to add a Constraint member to
ColumnDef, and pre-process so that we attach the correct constraint
definition to each column definition before invoking
transformIndexConstraints in transformCreateStmt; we already do the
match there, so it would be a good place for that.  Alternatively, turn
is_not_null into a tristate (yes, no, "yes but is no inherit").

[1] https://github.com/alvherre/postgres/commit/22e5820e241c744fb36cbc643a4d8d94162c562e

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"The problem with the facetime model is not just that it's demoralizing, but
that the people pretending to work interrupt the ones actually working."
                  -- Paul Graham, http://www.paulgraham.com/opensource.html



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: POC, WIP: OR-clause support for indexes
Next
From: jian he
Date:
Subject: Re: meson and check-tests