Domains vs data types

On 8/19/25 21:47, Ertan Küçükoglu wrote:

Hello,

I am using PostgreSQL 17.6.
I would like to learn if there is any benefit of using domains over data
types for table column definitions in terms of performance gain/loss.

For example I might have table defined as below
create table test (
  a integer,
  b integer,
  c integer,
  d varchar(5)
);

I might also have ame table defined as below

create domain aint integer;
create domain s5 varchar(5);

create table test_domain (
  a aint,
  b aint,
  c aint,
  d s5
);

Does the second table have any technical advantage/disadvantage over
plain data type definition?
Less metadata in memory? High metadata in memory? Less/increased disk space?

See:

https://www.postgresql.org/docs/current/catalog-pg-type.html

for what is stored in system catalog for a domain vs a base type.

Personally I don't see that integer --> aint really helps.
Also I am pretty sure varchar(5) --> s5 is still going to result in a
length check.

Thanks & Regards,
Ertan

--
Adrian Klaver
adrian.klaver@aklaver.com

On Wed, Aug 20, 2025 at 11:05 AM Adrian Klaver <adrian.klaver@aklaver.com>
wrote:
[snip]

Personally I don't see that integer --> aint really helps.

No one's going to create the domain "aint", but a DB designer in a rigorous
environment _will_ create multiple, meaningfully-named domains, all of
which happen to be INTEGER. Makes large-team developing easier.

The alternative is Really Really Long column names, and consistent use of
agreed-upon suffixes.

--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!

On Wed, Aug 20, 2025 at 12:48 AM Ertan Küçükoglu <ertan.kucukoglu@gmail.com>
wrote:

Does the second table have any technical advantage/disadvantage over plain
data type definition?
Less metadata in memory? High metadata in memory? Less/increased disk
space?

Same disk space. No disadvantage other than confusing your users, and any
performance differences will be so minor as to be unmeasurable. (my two
cents: domains are best when the data type is complex AND shared across
multiple tables. Even then I tend to avoid them.)

Cheers,
Greg

--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support

Opinion: domains are useful if you give them names that are full of
meaning. For example if you have the same type of data accross tables
"item_number" or "account" etc so that you can use them to describe what
you want stored in them and ensure the same defaults, nulls etc are applied
accross tables. Having randomly named or encoded lists just makes life more
complicated.

On Wed, 20 Aug 2025, 18:13 Greg Sabino Mullane, <htamfids@gmail.com> wrote:

On Wed, Aug 20, 2025 at 9:57 AM Ron Clarke <rclarkeai@gmail.com> wrote:

...and ensure the same defaults, nulls etc are applied accross tables.

Just as a warning - a deviation we have from the SQL Standard regarding
domains and their NOT NULL constraints makes specifying one on a domain a
bit of a potential trap. Rely on column NOT NULL.

David J.

On 20 Aug 2025, at 7:47 AM, Ertan Küçükoglu <ertan.kucukoglu@gmail.com> wrote:

Hello,

I am using PostgreSQL 17.6.
I would like to learn if there is any benefit of using domains over data types for table column definitions in terms of performance gain/loss.

I know that this doesn’t answer your question, but before exploring custom types / domains,
and based on experience, I’d strongly recommend exploring jsonb instead as an alternative.

Also note that using custom types can lead to some confusion initially for basic stuff
you can’t do things like SELECT mytype.f1 and instead you have to do (mytype).f1
Things like this can get annoying pretty quickly.

On Wed, Aug 20, 2025 at 7:37 PM Florents Tselai
<florents.tselai@gmail.com> wrote:

On 20 Aug 2025, at 7:47 AM, Ertan Küçükoglu <ertan.kucukoglu@gmail.com> wrote:
I would like to learn if there is any benefit of using domains over data types for table column definitions in terms of performance gain/loss.

I know that this doesn’t answer your question, but before exploring custom types / domains,
and based on experience, I’d strongly recommend exploring jsonb instead 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 complexity
themselves of constrained data (must expect anything). Your SQL also becomes
less expressive or more complex, although PostgreSQL has excellent JSON support.

Also note that using custom types can lead to some confusion initially for basic stuff
you can’t 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_type.
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 OIDs
for custom types. But few people care about such things.

FWIW, --DD

On Thu, Aug 21, 2025 at 2:11 AM Dominique Devienne <ddevienne@gmail.com> wrote:

On Wed, Aug 20, 2025 at 7:37 PM Florents Tselai
<florents.tselai@gmail.com> wrote:

On 20 Aug 2025, at 7:47 AM, Ertan Küçükoglu <ertan.kucukoglu@gmail.com> wrote:
I would like to learn if there is any benefit of using domains over data types for table column definitions in terms of performance gain/loss.

I know that this doesn’t answer your question, but before exploring custom types / domains,
and based on experience, I’d strongly recommend exploring jsonb instead 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.

+1 this.

The main use for domains is to allow for standard constraints. If
you find yourself writing the same constraint over and over, that's
when you might consider using them.

For example, in the USA, vehicle identification numbers must be
exactly 17 characters long.

postgres@postgres=# create domain vin as text check (length(VALUE) = 17);
CREATE DOMAIN
postgres@postgres=# select 'abc'::TEXT::VIN;
ERROR: value for domain vin violates check constraint "vin_check"

The other use for domains I see is global sequences where you have
many tables pulling from the same sequence.

postgres@postgres=# create sequence global_id_seq;
CREATE SEQUENCE
postgres@postgres=# create domain global_id as bigint default
nextval('global_id_seq');
CREATE DOMAIN

Using domains is not really a performance thing, it's more regarding
establishing rigor around type rules. In general, I tend not to use
length constraints for tex columns anymore for most cases (just use
text!), but I could get behind setting some standard length
constraints, say, capped at 1k characters as a safety precaution.

merlin

merlin