| 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 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Janes | 2009-08-29 22:01:03 | Re: What exactly is postgres doing during INSERT/UPDATE ? |
| Previous Message | Tom Lane | 2009-08-29 21:45:24 | Re: PostgreSQL does CAST implicitely between int and a domain derived from int |