Re: Adding a nullable DOMAIN column w/ CHECK - Mailing list pgsql-hackers

From Noah Misch
Subject Re: Adding a nullable DOMAIN column w/ CHECK
Date
Msg-id 20140907045539.GD1066341@tornado.leadboat.com
Whole thread Raw
In response to Adding a nullable DOMAIN column w/ CHECK  (Marko Tiikkaja <marko@joh.to>)
Responses Re: Adding a nullable DOMAIN column w/ CHECK
List 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 by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Improving PL/PgSQL (was: Re: plpgsql defensive mode)
Next
From: Peter Geoghegan
Date:
Subject: Re: B-Tree support function number 3 (strxfrm() optimization)