Re: Help with a seq scan on multi-million row table - Mailing list pgsql-sql

From Tom Lane
Subject Re: Help with a seq scan on multi-million row table
Date
Msg-id 22508.1147307221@sss.pgh.pa.us
Whole thread Raw
In response to Help with a seq scan on multi-million row table  (<ogjunk-pgjedan@yahoo.com>)
Responses Re: Help with a seq scan on multi-million row table
List pgsql-sql
<ogjunk-pgjedan@yahoo.com> writes:
>                ->  Hash Join  (cost=2797.65..140758.50 rows=3790 width=10) (actual time=248.530..380635.132 rows=8544
loops=1) 
 
>                      Hash Cond: ("outer".user_url_id = "inner".id)  
>                      ->  Seq Scan on user_url_tag userurltag0_  (cost=0.00..106650.30 rows=6254530 width=14) (actual
time=0.017..212256.630rows=6259553 loops=1)  
 
>                      ->  Hash  (cost=2795.24..2795.24 rows=962 width=4) (actual time=199.840..199.840 rows=0 loops=1)

 
>                            ->  Index Scan using ix_user_url_user_id_url_id on user_url userurl1_  (cost=0.00..2795.24
rows=962width=4) (actual time=0.048..193.707 rows=1666 loops=1)  
 
>                                  Index Cond: (user_id = 1)  

Hm, I'm not sure why it's choosing that join plan.  A nestloop indexscan
wouldn't be terribly cheap, but just counting on my fingers it seems
like it ought to come in at less than 100000 cost units.  What do you
get if you set enable_hashjoin off?  (Then try disabling its
second-choice join type too --- I'm interested to see EXPLAIN ANALYZE
output for all three join types.)

What PG version is this exactly?
        regards, tom lane


pgsql-sql by date:

Previous
From:
Date:
Subject: Re: Help with a seq scan on multi-million row table
Next
From:
Date:
Subject: Re: Help with a seq scan on multi-million row table