MIME-Version: 1.0
References: <CAH2i4yf_M5NfX_kDu6_2Z+sgqLOZK9vCsF3EfmwZQyYFuAMxpg@mail.gmail.com>
 <524E00FE-DBFF-483B-A276-467A0B979B1D@gmail.com>
In-Reply-To: <524E00FE-DBFF-483B-A276-467A0B979B1D@gmail.com>
From: Dominique Devienne <ddevienne@gmail.com>
Date: Thu, 21 Aug 2025 10:11:08 +0200
Message-ID: <CAFCRh-9n3Hf+D0fNKX4UQ34WxFSCz+SUUiB8T5EGyj9206yCMQ@mail.gmail.com>
Subject: Re: Domains vs data types
To: Florents Tselai <florents.tselai@gmail.com>
Cc: =?UTF-8?B?RXJ0YW4gS8O8w6fDvGtvZ2x1?= <ertan.kucukoglu@gmail.com>, 
	pgsql-general@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAFCRh-9n3Hf%2BD0fNKX4UQ34WxFSCz%2BSUUiB8T5EGyj9206yCMQ%40mail.gmail.com>
Precedence: bulk

On Wed, Aug 20, 2025 at 7:37=E2=80=AFPM Florents Tselai
<florents.tselai@gmail.com> wrote:
> > On 20 Aug 2025, at 7:47=E2=80=AFAM, Ertan K=C3=BC=C3=A7=C3=BCkoglu <ert=
an.kucukoglu@gmail.com> wrote:
> > I would like to learn if there is any benefit of using domains over dat=
a types for table column definitions in terms of performance gain/loss.


> I know that this doesn=E2=80=99t answer your question, but before explori=
ng custom types / domains,
> and based on experience, I=E2=80=99d strongly recommend exploring jsonb i=
nstead as an alternative.

I stayed out of that thread, but this makes me step out and react.
domains are typically out constraining the value space of a type.
I.e. a type with a CHECK constraint. W/o one, it's pretty useless IMHO.

While json/jsonb is about denormalizing and stuffing unconstrained data,
of arbitrary (and often evolving) content. No need for complex relational
modeling and its associated constraints and "rigidity". I.e. easy evolution
of the data tier, at the cost of applications having to deal with the compl=
exity
themselves of constrained data (must expect anything). Your SQL also become=
s
less expressive or more complex, although PostgreSQL has excellent JSON sup=
port.

> Also note that using custom types can lead to some confusion initially fo=
r basic stuff
> you can=E2=80=99t do things like SELECT mytype.f1 and instead you have to=
 do (mytype).f1

I guess you're talking about composite types? Not sure OP had that in mind.
But that's still a good point. Thanks for sharing.

Yes, using a custom type/domain is more metadata, since a new row in pg_typ=
e.
But that's mostly negligeable.

There's always an (integral) OID associated to columns, so only its value
changes if you start using a custom type, be it i memory or on disk. So no,
using a custom type is unlikely to make things bigger or slower.

That said, in my case, because I use the BINARY mode of LIBPQ and COPY,
it does matter, as my code knows about built-in OIDs, but not of custom OID=
s
for custom types. But few people care about such things.

FWIW, --DD