Re: PostgreSQL does CAST implicitely between int and a domain derived from int - Mailing list pgsql-performance

From Jean-Michel Pouré
Subject Re: PostgreSQL does CAST implicitely between int and a domain derived from int
Date
Msg-id 1251579586.11765.14.camel@acer
Whole thread Raw
In response to Re: PostgreSQL does CAST implicitely between int and a domain derived from int  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: PostgreSQL does CAST implicitely between int and a domain derived from int
List pgsql-performance
Le samedi 29 août 2009 à 13:44 -0400, Tom Lane a écrit :
> That domain doesn't have any operators of its own.  To compare to
> another value, or use an index, you have to cast it to integer which
> does have operators.  It's a no-op cast, but logically necessary.

Dear Tom,

Thanks for answering. On more question:

Drupal makes use these no-op CREATE DOMAINs in the database schema :

CREATE DOMAIN int_unsigned
  AS integer
   CONSTRAINT int_unsigned_check CHECK ((VALUE >= 0));

CREATE DOMAIN bigint_unsigned
  AS bigint
   CONSTRAINT bigint_unsigned_check CHECK ((VALUE >= 0));

CREATE DOMAIN smallint_unsigned
  AS smallint
   CONSTRAINT smallint_unsigned_check CHECK ((VALUE >= 0));

CREATE DOMAIN varchar_ci
  AS character varying(255)
  DEFAULT ''::character varying
  NOT NULL;

In my slow queries, I can notice excessive no-op casts. Do you think
this could lead to excessive sequential scans?

What do you recommend: using normal types and moving constraints in the
Drupal database? Is PostgreSQL domain broken as it forces casting or is
this a no-op for performance?

What do you recommend?

Kind regards,
Jean-Michel

Attachment

pgsql-performance by date:

Previous
From: David Rees
Date:
Subject: Re: What exactly is postgres doing during INSERT/UPDATE ?
Next
From: Tom Lane
Date:
Subject: Re: PostgreSQL does CAST implicitely between int and a domain derived from int