Peter Eisentraut <peter_e@xxxxxxx> writes: > OK, upgrading to 8.2.4 fixes this odd plan choice. The query does run > a bit faster too, but the cost estimate has actually gone up! Yeah, because the former code was making an unrealistically small estimate of the number of tuples found by BitmapAnd (due to double-counting the selectivities of redundant indexes), and of course that means a smaller estimate of the cost to fetch them in the bitmap heap scan. regards, tom lane
