Re: Document atthasmissing default optimization avoids verification table scan

On Fri, Jan 21, 2022 at 2:08 PM Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:

> On 1/21/22 13:55, James Coleman wrote:
>
> + Before <productname>PostgreSQL</productname> 11, adding a new
> column to a
> + table required rewriting that table, making it a very slow operation.
> + More recent versions can sometimes optimize away this rewrite and
> related
> + validation scans. See the notes in <command>ALTER TABLE</command>
> for details.
>
>
> 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 combined effect of "sometimes", "in many", "can be", and "an
appropriate" make this version harder to read than it probably needs to
be. I like the patch as-is over this; but I would want to give an
alternative wording more thought if it is insisted upon that mention of
PostgreSQL 11 goes away.

David J.