Peter Eisentraut <peter_e(at)gmx(dot)net> 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