The only thing I can think of is perhaps his primary index drastically needs repacking. Otherwise, isn't there a real anomaly here? Halving the key width might account for some of it, but it's still miles out of court.
Actually, I'm surprised the planner came up with such a low cost for the single column index, unless ... perhaps correlation statistics aren't used when determining costs for multi-column indexes?
Josh Berkus wrote:
Pretty simple, really. Look at the cost calculations for the index scan for the multi-column index. PostgreSQL believes that:
The cost of a seq scan is 4788.14
The cost of an 2-column index scan is 36720.39
The cost of a 1-column index scan is 916.24
Assuming that you ran each of these queries multiple times to eliminate caching as a factor, the issue is that the cost calculations are wrong. We give you a number of GUC variables to change that:
effective_cache_size
random_page_cost
cpu_tuple_cost
etc.
See the RUNTIME-CONFIGURATION docs for more details.
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
