From: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
---|---|
To: | John Aughey <jha(at)washucsc(dot)org> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Unusual slowdown using subselects |
Date: | 2001-05-16 22:09:08 |
Message-ID: | Pine.BSF.4.21.0105161508330.29915-100000@megazone23.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> calendar=# explain select * from schedule where schedule.owner_id in
> (select group_id from groups where user_id=101);
> NOTICE: QUERY PLAN:
> Seq Scan on schedule (cost=0.00..2039895.00 rows=1000000 width=40)
> SubPlan
> -> Materialize (cost=2.02..2.02 rows=1 width=4)
> -> Index Scan using groups_id_index on groups (cost=0.00..2.02
> rows=1 width=4)
>
> You'll see in this one, where the first example did a index scan, this one
> with a very similar query does a seq scan. The two queries should be
> nearly identical, but this one runs very slowly.
>
> Can anyone explain why this happens and/or how I can do a sub-select like
> this and get fast results?
Try using EXISTS rather than IN (see the FAQ for more information).
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Patterson | 2001-05-16 22:52:11 | plperl in 7.1 |
Previous Message | Alexander Dederer | 2001-05-16 22:01:21 | Why index don't use with SELECT |