Re: cataloguing NOT NULL constraints
От | Bruce Momjian |
---|---|
Тема | Re: cataloguing NOT NULL constraints |
Дата | |
Msg-id | ZkQRCO3sSMPdqmyF@momjian.us обсуждение исходный текст |
Ответ на | Re: cataloguing NOT NULL constraints (Robert Haas <robertmhaas@gmail.com>) |
Список | 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 по дате отправления: