Re: Document atthasmissing default optimization avoids verification table scan

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: Document atthasmissing default optimization avoids verification table scan
Дата
Msg-id CAKFQuwbzYj2QZQAcquHH+S7YWxsNU0r6EiNZVW7JTBBvycU6BA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Document atthasmissing default optimization avoids verification table scan  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: Document atthasmissing default optimization avoids verification table scan  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Fri, Jan 21, 2022 at 2:08 PM Andrew Dunstan <andrew@dunslane.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.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: A test for replay of regression tests
Следующее
От: Robert Haas
Дата:
Сообщение: fairywren is generating bogus BASE_BACKUP commands