Re: excessive disk access during query - Mailing list pgsql-performance

From Tom Lane
Subject Re: excessive disk access during query
Date
Msg-id 2500.1057066973@sss.pgh.pa.us
Whole thread Raw
In response to excessive disk access during query  (Toby Sargeant <sargeant@wehi.edu.au>)
List pgsql-performance
Toby Sargeant <sargeant@wehi.edu.au> writes:
>  Merge Join  (cost=0.00..448139.41 rows=14786 width=52) (actual time=1582.24..125624.92 rows=2140 loops=1)
>    Merge Cond: ("outer".seq_text_id = "inner".id)
>    ->  Index Scan using seq_text_map_seq_text_index on seq_text_map  (cost=0.00..154974.74 rows=2957158 width=48)
(actualtime=23.04..110877.65 rows=2956147 loops=1) 
>    ->  Index Scan using seq_text_pkey on seq_text  (cost=0.00..285540.03 rows=17174 width=4) (actual
time=71.51..12260.38rows=3077 loops=1) 
>          Filter: (lower(text) ~~ '%porin%'::text)
>  Total runtime: 125627.45 msec

I'm surprised it doesn't try to use a hash join instead.  Are the
datatypes of seq_text_id and id different (if so, can you make them the
same?)  What sorts of plans and timings do you get if you flip
enable_mergejoin and/or enable_indexscan?

            regards, tom lane

pgsql-performance by date:

Previous
From: "scott.marlowe"
Date:
Subject: Re: FW: Version 7 question
Next
From: "Michael Mattox"
Date:
Subject: Re: Version 7 question