Date: Thu, 9 Feb 2023 10:56:35 +0000 (GMT)
From: Mark Hills <mark@xwax.org>
To: Laurenz Albe <laurenz.albe@cybertec.at>
cc: pgsql-performance@lists.postgresql.org
Subject: Re: Domain check taking place unnecessarily?
In-Reply-To: <4b1a0c9e36280b1d4abeb4fb6336832409df6ae0.camel@cybertec.at>
Message-ID: <2302091035450.14632@stax.localdomain>
References: <2302081605290.5352@stax.localdomain>
 <4b1a0c9e36280b1d4abeb4fb6336832409df6ae0.camel@cybertec.at>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="-1463793916-464543087-1675940196=:14632"
Archived-At: 
 <https://www.postgresql.org/message-id/2302091035450.14632%40stax.localdomain>
Precedence: bulk

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---1463793916-464543087-1675940196=:14632
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Wed, 8 Feb 2023, Laurenz Albe wrote:

> On Wed, 2023-02-08 at 18:01 +0000, Mark Hills wrote:
> > I've ruled out waiting on a lock; nothing is reported with=20
> > log_lock_waits=3Don. This is a test database with exclusive access (2.5=
=20
> > million rows):
> >=20
> > This is PostgreSQL 14.5 on Alpine Linux. Thanks.
> >=20
> > CREATE DOMAIN hash AS text
> > =C2=A0=C2=A0=C2=A0 CHECK (VALUE ~ E'^[a-zA-Z0-9]{8,32}$');
> > =C2=A0
> > devstats=3D> ALTER TABLE invite ADD COLUMN test text;
> > ALTER TABLE
> > Time: 8.988 ms
> > =C2=A0
> > devstats=3D> ALTER TABLE invite ADD COLUMN test hash;
> > ALTER TABLE
> > Time: 30923.380 ms (00:30.923)
> > =C2=A0
> > devstats=3D> ALTER TABLE invite ADD COLUMN test hash DEFAULT NULL;
> > ALTER TABLE
> > Time: 30344.272 ms (00:30.344)
> > =C2=A0
> > devstats=3D> ALTER TABLE invite ADD COLUMN test hash DEFAULT '123abc123=
'::hash;
> > ALTER TABLE
> > Time: 67439.232 ms (01:07.439)
>=20
> It takes 30 seconds to schan the table and determine that all existing=20
> 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=20
domain check is guaranteed to be immutable (per [1] in my original mail)

Of course, if it were a table constraint it may involve multiple columns,=
=20
requiring it to be evaluated per-row.

But the docs make it clear the domain check is expected to be evaluated on=
=20
input, precisely for this purpose.

So I wondered if this was a shortcoming or even a bug.

It seems that adding a column of NULL (or even default) values for a=20
domain can (should?) be as quick as a basic data type like text or=20
integer...?

--=20
Mark
---1463793916-464543087-1675940196=:14632--