Re: excessive disk access during query

Toby Sargeant <sargeant(at)wehi(dot)edu(dot)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) (actual time=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.38 rows=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