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
Thanks,
-Prasanth.
Scott Marlowe wrote:
> On Thu, 2005-05-12 at 10:05, Prasanth wrote:
>
>>When joining two tables the query plan is doing a seq scan rather than index
>>scan. I do have indexes on the columns used for joining the tables.
>>
>>Example:
>>SELECT a.id FROM a, b WHERE a.id = b.id;
>>
>> QUERY PLAN
>>-----------------------------------------------------------------------------------------
>> Hash Join (cost=13865.30..326413.23 rows=6451 width=18)
>> Hash Cond: ("outer".id = "inner".id)
>> -> Seq Scan on a (cost=0.00..125076.37 rows=6450937 width=18)
>> -> Hash (cost=10168.64..10168.64 rows=500664 width=4)
>> -> Seq Scan on b (cost=0.00..10168.64 rows=500664 width=4)
>>(5 rows)
>>
>>
>>The planner used to perform a index scan. I have added a lot of data in those
>>two tables. Right now both tables have millions of records. After adding the new
>>records the planner is going for a seq scan while doing the join.
>>
>>Is there any tunning I can do so that the query planner would do a index scan?
>>
>>I did a vacuum analyze but no change.
>
>
> try this:
>
> explain analyze SELECT a.id FROM a, b WHERE a.id = b.id;
> set enable_seqscan=off;
> explain analyze SELECT a.id FROM a, b WHERE a.id = b.id;
>
> and see which is faster.
>
> It's quite likely that using an index here makes no sense, since there's
> no selectivity happening, and you need all the data anyway.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
>
>
