Re: Document atthasmissing default optimization avoids verification table scan

On Wed, Jan 19, 2022 at 5:08 PM Bossart, Nathan <bossartn(at)amazon(dot)com> wrote:

> 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?
>

As a side-effect of rewriting every live record in the table and indexes to
brand new files, yes. I doubt an actual independent scan was performed
since the only way for the newly written tuples to not have the default
value inserted would be a severe server bug.

> + 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?
>
>
This doesn't seem like relevant material to comment on. It's an
implementation detail that is sufficiently covered by "making the ALTER
TABLE very fast even on large tables".

Also, the idea of performing that scan seems ludicrous. I just added the
column and told it to populate with default values - why do you need to
check that your server didn't miss any?

David J.