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,
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 row
I've got this query with an IN clause:
select count(*),public.album.gid,public.album.name,public.album.id
from public.album,public.albumjoin,public.puid,public.puidjoin where
albumjoin.album = public.album.id and public.puidjoin.track =
public.albumjoin.track and public.puid.id = public.pui
Luke Lonergan wrote:
>
> I think the topic is similar to "cache bypass", used in cache capable vector
> processors (Cray, Convex, Multiflow, etc) in the 90's. When you are
> scanning through something larger than the cache, it should be marked
> "non-cacheable" and bypass caching altogether. Thi
