Re: Adding a nullable DOMAIN column w/ CHECK

Поиск
Список
Период
Сортировка
От Noah Misch
Тема Re: Adding a nullable DOMAIN column w/ CHECK
Дата
Msg-id 20140907045539.GD1066341@tornado.leadboat.com
обсуждение исходный текст
Ответ на Adding a nullable DOMAIN column w/ CHECK  (Marko Tiikkaja <marko@joh.to>)
Ответы Re: Adding a nullable DOMAIN column w/ CHECK  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Sat, Sep 06, 2014 at 02:01:32AM +0200, Marko Tiikkaja wrote:
> First of all, sorry about breaking the thread; I don't subscribe to
> -general so I can't copy the original email.  This is in response to
> the problem here:
http://www.postgresql.org/message-id/CACfv+p+8dToaR7h06_M_YMjpV5Na-CQq7kN=KgJq_k84H7UHWA@mail.gmail.com

You can download the message via "view raw" in the web archives, open it as an
mbox file, and reply there.

The old thread was fuzzy concerning how the system works today.  Adding a
domain-type column rewrites the table unless the domain has no constraints.
Simultaneously adding an all-NULL column and a CHECK constraint to a table
scans the table, even if the CHECK constraint references only the new column.

> The patch is obviously a load of horse crap, but does anyone have
> any objections to the general approach of making this pattern
> faster?

+1 in general.

> To do this optimization we do have to assume that CHECKs in
> DOMAINs are at least STABLE, but I don't see that as a problem;
> those should be IMMUTABLE anyway, I think.

The system has such assumptions already.



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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: Improving PL/PgSQL (was: Re: plpgsql defensive mode)
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: B-Tree support function number 3 (strxfrm() optimization)