Carlos Benkendorf <carlosbenkendorf@xxxxxxxxxxxx> writes: > Hi, > > We´re running 8.03 and I´m trying to understand why the following SELECT doesn´t use iarchave05 index. > > If you disable seqscan then iarchave05 index is used and the total runtime > is about 50% less than when iarchave05 index is not used. > > Why is the optimizer not using iarchave05 index? The optimizer is calculating that the index scan would require more i/o than the sequential scan and be slower. The only reason it isn't is because most of the data is cached from your previous tests. If this test accurately represents the production situation and most of this data is in fact routinely cached then you might consider lowering the random_page_cost to represent this. The value of 4 is reasonable for actual i/o but if most of the data is cached then you effectively are getting something closer to 1. Try 2 or 1.5 or so. Note that the sequential scan has to scan the entire table. The index scan has to scan the entire table *and* the entire index, and in a pretty random order. If the table didn't fit entirely in RAM it would end up reading the entire table several times over. -- greg
