Thanks for the prompt reply.
Table a has about 6 million and table b had a little more than half a million.
Sorry I wasn't exact about my numbers before.
I will be having the where conditions on both the tables that would bring down
the count drastically. Even in this case the planner is going for a seq scan.
A where condition I always use is shown below. This is bringing down the number
of rows from 6.5m to 1210. I have an index on code also. Even here it is going
for seq scan.
EXPLAIN ANALYZE SELECT count(*) fROM a where Code >2;
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------
Aggregate (cost=141321.09..141321.09 rows=1 width=0) (actual
time=6454.063..6454.064 rows=1 loops=1)
-> Seq Scan on a (cost=0.00..141318.40 rows=1076 width=0) (actual
time=15.687..6453.292 rows=1210 loops=1)
Filter: (code > 2)
Total runtime: 6454.140 ms
(4 rows)
Below is example where I have where conditions on both the tables this in effect
is limiting the number of rows from each tables a & b to 171 & 1076 respectively.
EXPLAIN (SELECT fund_value FROM b INNER JOIN a ON a.id = b.id WHERE code >2 AND
b.account_id = 16221);
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------
Merge Join (cost=141372.58..141462.28 rows=1 width=8)
Merge Cond: ("outer".id = "inner".id)
-> Index Scan using id_idx on b (cost=0.00..14415.96 rows=171 width=4)
Filter: (account_id = 16221)
-> Sort (cost=141372.58..141375.27 rows=1076 width=12)
Sort Key: a.id
-> Seq Scan on a (cost=0.00..141318.40 rows=1076 width=12)
Filter: (code > 2)
(8 rows)
Thanks,
-Prasanth.
Tom Lane wrote:
> Prasanth <dbadmin@xxxxxxxxxxx> writes:
>
>> 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.
>
>
> It is highly unlikely that you want an index scan for joining millions
> of records ...
>
> However, if you do have millions in both tables, why does the planner
> think there are only 500664 rows in b? Maybe you are overdue for ANALYZE.
>
> regards, tom lane
>
>
