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
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
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
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,
