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