Re: cataloguing NOT NULL constraints - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: cataloguing NOT NULL constraints
Date
Msg-id ZkQRCO3sSMPdqmyF@momjian.us
Whole thread Raw
In response to Re: cataloguing NOT NULL constraints  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Mon, May 13, 2024 at 09:00:28AM -0400, Robert Haas wrote:
> > Specifically, the problem is that I mentioned that we could restrict the
> > NOT NULL NO INHERIT addition in pg_dump for primary keys to occur only
> > in pg_upgrade; but it turns this is not correct.  In normal
> > dump/restore, there's an additional table scan to check for nulls when
> > the constraints is not there, so the PK creation would become measurably
> > slower.  (In a table with a million single-int rows, PK creation goes
> > from 2000ms to 2300ms due to the second scan to check for nulls).
> 
> I have a feeling that any theory of the form "X only needs to happen
> during pg_upgrade" is likely to be wrong. pg_upgrade isn't really
> doing anything especially unusual: just creating some objects and
> loading data. Those things can also be done at other times, so
> whatever is needed during pg_upgrade is also likely to be needed at
> other times. Maybe that's not sound reasoning for some reason or
> other, but that's my intuition.

I assume Alvaro is saying that pg_upgrade has only a single session,
which is unique and might make things easier for him.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Only you can decide what is important to you.



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: cataloguing NOT NULL constraints
Next
From: jian he
Date:
Subject: Re: explain format json, unit for serialize and memory are different.