Vincent van Leeuwen <pgsql.spam@vinz.nl> writes:
> How did you calculate the value of 3?
Estimated cost of an indexscan is approximately proportional to
random_page_cost, but cost of a seqscan isn't affected by it.
You had a hash join plan that used two seqscans (so its estimated
cost is unaffected by random_page_cost) plus a merge join plan
that had one indexscan input. I just extrapolated the change in
the indexscan cost needed to make the ratio of total costs agree with
reality. This is a pretty rough calculation of course, but I don't
believe small values of random_page_cost except for situations where all
your data is buffered in RAM. It's real easy to get led down the garden
path by small test cases that get fully buffered (especially when you
repeat them over and over), and pick cost values that will not reflect
reality in a production environment. I can't say whether that actually
happened to you, but it's something to be on your guard about.
> Another problem we've noticed is that on an idle database certain queries are
> better off using an indexscan than a seqscan, something which the planner
> already wanted to do. But when the load on the database gets a lot higher,
> indexscans are consistently slower than seqscans (same query, same
> parameters).
See above. Increasing load reduces the chances that any one query will
find its data already buffered, since there's more competition for the
available buffer space.
> Does 7.4 already have changes in this area that will affect this query?
No.
regards, tom lane