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 <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
