Re: Document atthasmissing default optimization avoids verification table scan

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Fri, Jan 21, 2022 at 2:08 PM Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>> I know what it's replacing refers to release 11, but let's stop doing
>> that. How about something like this?
>>
>> Adding a new column can sometimes require rewriting the table,
>> making it a very slow operation. However in many cases this rewrite
>> and related verification scans can be optimized away by using an
>> appropriate default value. See the notes in <command>ALTER
>> TABLE</command> for details.

> I think it is a virtue, and am supported in that feeling by the existing
> wording, to be explicit about the release before which these optimizations
> can not happen. The docs generally use this to good effect without
> overdoing it. This is a prime example.

The fact of the matter is that optimizations of this sort have existed
for years. (For example, I think we've optimized away the rewrite
when the new column is DEFAULT NULL since the very beginning.) So it
does not help to write the text as if there were no such optimizations
before version N and they were all there in N.

I agree that Andrew's text could stand a pass of "omit needless words".
But I also think that we could be a bit more explicit about what "slow"
means. Maybe like

Adding a new column can require rewriting the whole table,
making it slow for large tables. However the rewrite can be optimized
away in some cases, depending on what default value is given to the
column. See <command>ALTER TABLE</command> for details.

(the ALTER TABLE reference should be a link, too)

regards, tom lane