Re: Query Plan - Index Scan & Seq Scan - Mailing list pgsql-admin

From Scott Marlowe
Subject Re: Query Plan - Index Scan & Seq Scan
Date
Msg-id 1115911416.3868.265.camel@state.g2switchworks.com
Whole thread Raw
In response to Query Plan - Index Scan & Seq Scan  (Prasanth <dbadmin@nqadmin.com>)
Responses Re: Query Plan - Index Scan & Seq Scan  (Prasanth <dbadmin@nqadmin.com>)
List pgsql-admin
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.

pgsql-admin by date:

Previous
From: Scott Marlowe
Date:
Subject: Re: memory allocation ; postgresql-8.0
Next
From: Gourish Singbal
Date:
Subject: Help with connections