Re: Adding a nullable DOMAIN column w/ CHECK

From: Noah Misch <noah(at)leadboat(dot)com>
To: Marko Tiikkaja <marko(at)joh(dot)to>
Cc: PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>, Joe Van Dyk <joe(at)tanga(dot)com>
Subject: Re: Adding a nullable DOMAIN column w/ CHECK
Date: 2014-09-07 04:55:39
Message-ID: 20140907045539.GD1066341@tornado.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2014-09-07 04:57:14 Re: B-Tree support function number 3 (strxfrm() optimization)
Previous Message Pavel Stehule 2014-09-07 04:41:01 Re: Improving PL/PgSQL (was: Re: plpgsql defensive mode)