Re: Document atthasmissing default optimization avoids verification table scan

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, James Coleman <jtc331(at)gmail(dot)com>, "Bossart, Nathan" <bossartn(at)amazon(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Document atthasmissing default optimization avoids verification table scan
Date: 2022-01-21 22:38:32
Message-ID: 1289019.1642804712@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> You've removed the "constraint verification scan" portion of this.

Indeed, because that's got nothing to do with adding a new column
(per se; adding a constraint along with the column is a different
can of worms).

> Re-reading this, the recommendation:

> - However, if the default value is volatile (e.g.,
> - <function>clock_timestamp()</function>)
> - each row will need to be updated with the value calculated at the time
> - <command>ALTER TABLE</command> is executed. To avoid a potentially
> - lengthy update operation, particularly if you intend to fill the
> column
> - with mostly nondefault values anyway, it may be preferable to add the
> - column with no default, insert the correct values using
> - <command>UPDATE</command>, and then add any desired default as
> described
> - below.

> has now been completely removed from the documentation.

Really? That's horrid, because that's directly useful advice.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2022-01-21 22:41:58 Re: do only critical work during single-user vacuum?
Previous Message Tom Lane 2022-01-21 22:35:31 Re: fairywren is generating bogus BASE_BACKUP commands