>> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
