> It seems the cost assigned to a sequential scan over 120 million records is
> too low or, on the other side, the cost assigned to two nested loop over
> three indexes is too high.
It looks from here like you are measuring a situation where
vb_product_readings is fully cached in RAM. If that's the normal
situation in your database, then you ought to decrease the
random_page_cost setting to make the planner's cost estimates reflect
your reality. The default setting is intended to model situations
where a fair amount of disk access is going to happen.
regards, tom lane
In response to
pgsql-bugs by date
|Next:||From: lr||Date: 2012-08-01 01:15:21|
|Subject: BUG #6788: Can't compile on mingw64-w32|
|Previous:||From: gsaviane||Date: 2012-07-31 15:06:36|
|Subject: BUG #6787: Query planner estimates worng costs on nodes|