Date: Fri, 22 Feb 2013 22:34:21 +0100
From: Alexander Staubo <alex@bengler.no>
To: Kevin Grittner <kgrittn@ymail.com>
Cc: "=?utf-8?Q?pgsql-performance=40postgresql.org?="
	<pgsql-performance@postgresql.org>
Message-ID: <D0D7098559DD470B9C2DE753E74B83E4@gmail.com>
In-Reply-To: <1361566076.10158.YahooMailNeo@web162905.mail.bf1.yahoo.com>
References: <19B2B4ECC4724A438200C54257BA8B20@gmail.com>
	<1361566076.10158.YahooMailNeo@web162905.mail.bf1.yahoo.com>
Subject: Re: Bad query plan with high-cardinality column
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

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