Re: Query Plan - Index Scan & Seq Scan

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@nqadmin.com> 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
>
>