Skip site navigation (1) Skip section navigation (2)

Re: Why Index is not used

From: tv(at)fuzzy(dot)cz
To: "Adarsh Sharma" <adarsh(dot)sharma(at)orkash(dot)com>
Cc: "Chetan Suttraway" <chetan(dot)suttraway(at)enterprisedb(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Why Index is not used
Date: 2011-03-25 09:30:13
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
>>     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:

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.


In response to

pgsql-performance by date

Next:From: Vitalii TymchyshynDate: 2011-03-25 09:43:14
Subject: Re: Shouldn't we have a way to avoid "risky" plans?
Previous:From: Chetan SuttrawayDate: 2011-03-25 09:07:36
Subject: Re: Why Index is not used

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group