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? -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
