Re: IN not handled very well?

Ben <bench@silentmedia.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