Skip site navigation (1) Skip section navigation (2)

Re: PostgreSQL does CAST implicitely between int and a domain derived from int

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jean-Michel Pouré <jm(at)poure(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: PostgreSQL does CAST implicitely between int and a domain derived from int
Date: 2009-08-29 21:48:31
Message-ID: 407d949e0908291448h7a9566ao51b1f4ea0fdc706f@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Sat, Aug 29, 2009 at 10:45 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Jean-Michel =?ISO-8859-1?Q?Pour=E9?= <jm(at)poure(dot)com> writes:
>> 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?
>
> In principle it should be an unnoticeable slowdown.  In the past we've
> had some issues with the planner failing to recognize possible
> optimizations when there was a cast in the way, but I'm not aware of
> any such bugs at the moment.

In particular since your plan nodes are all index scans it's clear
that the casts are not getting in the way. The symptom when there were
problems was that the planner was forced to use sequential scans
because it couldn't match the casted expressionto the index expression
or some variant of that.


-- 
greg
http://mit.edu/~gsstark/resume.pdf

In response to

pgsql-performance by date

Next:From: Jeff JanesDate: 2009-08-29 22:01:03
Subject: Re: What exactly is postgres doing during INSERT/UPDATE ?
Previous:From: Tom LaneDate: 2009-08-29 21:45:24
Subject: Re: PostgreSQL does CAST implicitely between int and a domain derived from int

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group