Re: Bad query plan with high-cardinality column

On Friday, February 22, 2013 at 21:47 , Kevin Grittner wrote:
> I suspect you would be better off without those two indexes, and
> instead having an index on (conversation_id, created_at). Not just
> for the query you show, but in general.

Indeed, that solved it, thanks!

> In my experience these problems come largely from the planner not
> knowing the cost of dealing with each tuple. I see a lot less of
> this if I raise cpu_tuple_cost to something in the 0.03 to 0.05
> range.

Is this something I can just frob a bit without worrying about it adversely impacting database performance across the board, or should I be very careful and do lots of testing on a staging box first?