Date: Fri, 10 Feb 2023 10:49:25 +0000 (GMT)
From: Mark Hills <mark@xwax.org>
To: Tom Lane <tgl@sss.pgh.pa.us>, Laurenz Albe <laurenz.albe@cybertec.at>
cc: pgsql-performance@lists.postgresql.org
Subject: Re: Domain check taking place unnecessarily?
In-Reply-To: <3893890.1675955401@sss.pgh.pa.us>
Message-ID: <2302101040520.20262@stax.localdomain>
References: <2302081605290.5352@stax.localdomain>
 <4b1a0c9e36280b1d4abeb4fb6336832409df6ae0.camel@cybertec.at>
 <2302091035450.14632@stax.localdomain> <3893890.1675955401@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Archived-At: 
 <https://www.postgresql.org/message-id/2302101040520.20262%40stax.localdomain>
Precedence: bulk

On Thu, 9 Feb 2023, Tom Lane wrote:

> Mark Hills <mark@xwax.org> writes:
> > On Wed, 8 Feb 2023, Laurenz Albe wrote:
> >> It takes 30 seconds to schan the table and determine that all existing 
> >> rows satisky the constraint.
> 
> > But there's no existing data (note this is adding column, not constraint)
> 
> > Existing rows are guaranteed to satisfy the domain check, because the 
> > domain check is guaranteed to be immutable (per [1] in my original mail)
> 
> immutable != "will accept null".
> 
> There could be some more optimizations here, perhaps, but there aren't.

Well that's no problem at all. Thanks for the clarification.

I mentioned this case to a few people and they were also surprised by the 
outcome, to the point where we wondered if this might be misbehaving. 
Hence bringing it up in this forum.

We'll go ahead and deal with the pauses in production, as I don't think 
there's a workaround.

Thanks

-- 
Mark