Re: IN not handled very well?

Ah, so I do. Thanks, that helps an awful lot.

But the plan is still twice as expensive as when I put in the static
values. Is it just unreasonable to expect the planner to see that
there aren't many rows in the subselect, so to use the bitmap scans
after all?

On Sep 24, 2006, at 10:57 AM, Tom Lane wrote:

> 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