Skip site navigation (1) Skip section navigation (2)

Re: Query Plan - Index Scan & Seq Scan

From: Prasanth <dbadmin(at)nqadmin(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: Query Plan - Index Scan & Seq Scan
Date: 2005-05-12 15:44:32
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
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.

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:
         ->  Seq Scan on a  (cost=0.00..141318.40 rows=1076 width=12)
               Filter: (code > 2)
(8 rows)


Tom Lane wrote:
> Prasanth <dbadmin(at)nqadmin(dot)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

In response to


pgsql-admin by date

Next:From: Scott MarloweDate: 2005-05-12 15:51:26
Subject: Re: Query Plan - Index Scan & Seq Scan
Previous:From: Gourish SingbalDate: 2005-05-12 15:25:35
Subject: Help with connections

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group