From: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
---|---|
To: | James Coleman <jtc331(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Document atthasmissing default optimization avoids verification table scan |
Date: | 2022-01-20 00:08:07 |
Message-ID: | 90098862-68F6-4C57-B924-EF61CB12AAB3@amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 9/24/21, 7:30 AM, "James Coleman" <jtc331(at)gmail(dot)com> wrote:
> When PG11 added the ability for ALTER TABLE ADD COLUMN to set a constant
> default value without rewriting the table the doc changes did not note
> how the new feature interplayed with ADD COLUMN DEFAULT NOT NULL.
> Previously such a new column required a verification table scan to
> ensure no values were null. That scan happens under an exclusive lock on
> the table, so it can have a meaningful impact on database "accessible
> uptime".
I'm likely misunderstanding, but are you saying that adding a new
column with a default value and a NOT NULL constraint used to require
a verification scan?
+ Additionally adding a column with a constant default value avoids a
+ a table scan to verify no <literal>NULL</literal> values are present.
Should this clarify that it's referring to NOT NULL constraints?
Nathan
From | Date | Subject | |
---|---|---|---|
Next Message | Bossart, Nathan | 2022-01-20 00:36:32 | Re: Add checkpoint and redo LSN to LogCheckpointEnd log message |
Previous Message | Justin Pryzby | 2022-01-20 00:05:40 | Re: pg_upgrade should truncate/remove its logs before running |