Re: IN not handled very well?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ben <bench(at)silentmedia(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: IN not handled very well?
Date: 2006-09-24 17:57:54
Message-ID: 8361.1159120674@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Ben <bench(at)silentmedia(dot)com> writes:
> -> Hash IN Join (cost=51.67..31794.72
> rows=218 width=4)
> Hash Cond: (("outer".puid)::text =
> "inner".name)
> -> Seq Scan on puid
> (cost=0.00..23495.21 rows=1099421 width=44)

> -> Bitmap Heap Scan on puid
> (cost=20.03..59.52 rows=10 width=4)
> Recheck Cond: ((puid =
> 'f68dcf86-992c-2e4a-21fb-2fc8c56edfeb'::bpchar) OR (puid =
> '7716dbcf-56ab-623b-ab33-3b2e67a0727c'::bpchar) OR (puid =

Apparently you've got a datatype mismatch: name is text while puid is
char(N). The comparisons to name can't be converted into indexscans
on puid because the semantics aren't the same for text and char
comparisons.

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Ben 2006-09-24 18:12:25 Re: IN not handled very well?
Previous Message Ben 2006-09-24 17:12:23 IN not handled very well?