Re: Bad query plan with high-cardinality column - Mailing list pgsql-performance

From Alexander Staubo
Subject Re: Bad query plan with high-cardinality column
Date
Msg-id D0D7098559DD470B9C2DE753E74B83E4@gmail.com
Whole thread Raw
In response to Re: Bad query plan with high-cardinality column  (Kevin Grittner <kgrittn@ymail.com>)
Responses Re: Bad query plan with high-cardinality column  (Kevin Grittner <kgrittn@ymail.com>)
List pgsql-performance
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? 


pgsql-performance by date:

Previous
From: Alexander Staubo
Date:
Subject: Re: Bad query plan with high-cardinality column
Next
From: Kevin Grittner
Date:
Subject: Re: Bad query plan with high-cardinality column