Re: Re: Unusual slowdown using subselects

> In my DB:
> # explain SELECT * FROM grls WHERE grls.ag_id  = 24;
> NOTICE:  QUERY PLAN:
> Index Scan using grls_ag_id on grls  (cost=0.00..597.87 rows=849 width=122)
>
> # explain SELECT ag_id FROM agncs WHERE ag_id = 24;
> NOTICE:  QUERY PLAN:
> Seq Scan on agncs  (cost=0.00..1.31 rows=1 width=4)
>
> And together:
> # explain select * from grls where grls.ag_id in (select ag_id from agncs
> where ag_id = 24);
> NOTICE:  QUERY PLAN:
> Seq Scan on grls  (cost=0.00..40623.38 rows=30195 width=122)
>   SubPlan
>     ->  Materialize  (cost=1.31..1.31 rows=1 width=4)
>           ->  Seq Scan on agncs  (cost=0.00..1.31 rows=1 width=4)
> --------------------------------------
> # select count(*) from grls;
>  30195
>
> Summarize - with subselect indices ignores  and search look all DB rows.

Not quite.  in(<subselect>) doesn't use indexes (postgres doesn't realize
that this is effectively a join), but exists(<subselect>) often will,
and is the work around for the problem until it gets fixed (see FAQ
for more information - I forget the number, the title of the question
is something like "why are my subselects using in so slow."