EXPLAIN ANALYZE (SELECT id FROM a,b WHERE a.id = b.id AND code >2 AND
b.account_id = 16221);
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Merge Join (cost=141372.58..141462.28 rows=1 width=8) (actual
time=726.172..726.172 rows=0 loops=1)
Merge Cond: ("outer".id = "inner".id)
-> Index Scan using id_idx on b (cost=0.00..14415.96 rows=171 width=4)
(actual time=726.168..726.168 rows=0 loops=1)
Filter: (account_id = 16221)
-> Sort (cost=141372.58..141375.27 rows=1076 width=12) (never executed)
Sort Key: a.id
-> Seq Scan on a (cost=0.00..141318.40 rows=1076 width=12) (never
executed)
Filter: (code > 2)
Total runtime: 726.253 ms
(9 rows)
Thanks,
-Prasanth.
Scott Marlowe wrote:
> On Thu, 2005-05-12 at 10:51, Prasanth wrote:
>
>>I agree with you.
>>
>>But I have the where conditions on the tables I was expecting the planner to
>>user index scan but it went for seq scan.
>>
>>I did a little testing using what you said.
>>
>>Below are the results.
>>
>>SELECT a.id FROM a,b WHERE a.id = b.id AND a.code >2 AND b.account_id = 16221;
>>
>>Total runtime: 18194.936 ms
>>
>>Then I set the seqscan off and ran the same query.
>>
>>Total runtime: 27.554 ms
>
>
> Good! This tells us two things, 1: Your database can use the indexes
> (sometimes indexes can't be used for various reasons, which are quickly
> disappearing by the way.) and 2: Your database is making the wrong
> choice about when to use a seq scan versus an index.
>
> What does the explain analyze output from that query say about row
> estimates versus actual rows returned?
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>
>