>> Merge Join (cost=5673831.05..34033959.87 rows=167324179 width=2053)
>> Merge Cond: ((s.clause_id = c.clause_id) AND (s.doc_id =
>> c.source_id) AND (s.sentence_id = c.sentence_id))
>> -> Index Scan using idx_svo2 on svo2 s (cost=0.00..24489343.65
>> rows=27471560 width=1993)
>> -> Materialize (cost=5673828.74..6071992.29 rows=31853084
>> width=72)
>> -> Sort (cost=5673828.74..5753461.45 rows=31853084
>> width=72)
>> Sort Key: c.clause_id, c.source_id, c.sentence_id
>> -> Seq Scan on clause2 c (cost=0.00..770951.84
>> rows=31853084 width=72)
>>
>
> As per the size consideration and the number of rows, I think index scan
> on clause2 is better.
I really doubt that - using index usually involves a lot of random I/O and
that makes slow with a lot of rows. And that's exactly this case, as there
are 27471560 rows in the first table.
You can force the planner to use different plan by disabling merge join,
just set
set enable_mergejoin = false
and see what happens. There are other similar options:
http://www.postgresql.org/docs/8.4/static/runtime-config-query.html
And yet another option - you can try to mangle with the cost constants,
namely seq_page_cost and random_page_cost. Decreasing random_page_cost
(default is 4) makes index scans cheaper, so it's more likely the planner
will choose them.
Tomas
