Re: PostgreSQL does CAST implicitely between int and a domain derived from int
| От | Jean-Michel Pouré |
|---|---|
| Тема | Re: PostgreSQL does CAST implicitely between int and a domain derived from int |
| Дата | |
| Msg-id | 1251579586.11765.14.camel@acer обсуждение исходный текст |
| Ответ на | Re: PostgreSQL does CAST implicitely between int and a domain derived from int (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: PostgreSQL does CAST implicitely between int and a domain derived from int
|
| Список | 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
Вложения
В списке pgsql-performance по дате отправления: