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."