Received: from maia.hub.org (maia-3.hub.org [200.46.204.243])
	by mail.postgresql.org (Postfix) with ESMTP id B7197B5DBEE
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Mon, 26 Sep 2011 14:24:12 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia,
	port 10024) with ESMTP id 96235-02
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Mon, 26 Sep 2011 17:24:06 +0000 (UTC)
X-Greylist: delayed 00:08:14.54446 by SQLgrey-1.8.0-rc2
Received: from mail-gx0-f174.google.com (mail-gx0-f174.google.com
	[209.85.161.174])
	by mail.postgresql.org (Postfix) with ESMTP id EE18BB5DBE3
	for <pgsql-performance@postgresql.org>;
	Mon, 26 Sep 2011 14:24:05 -0300 (ADT)
Received: by gxk6 with SMTP id 6so4484665gxk.19
	for <pgsql-performance@postgresql.org>;
	Mon, 26 Sep 2011 10:24:05 -0700 (PDT)
Received: by 10.68.35.73 with SMTP id f9mr31206401pbj.92.1317057350011;
	Mon, 26 Sep 2011 10:15:50 -0700 (PDT)
Received: from Craig-Jamess-MacBook-Pro.local
	(wsip-70-167-122-86.sd.sd.cox.net. [70.167.122.86])
	by mx.google.com with ESMTPS id n10sm75106906pbe.4.2011.09.26.10.15.48
	(version=SSLv3 cipher=OTHER); Mon, 26 Sep 2011 10:15:48 -0700 (PDT)
Message-ID: <4E80B3F9.8070001@emolecules.com>
Date: Mon, 26 Sep 2011 10:18:49 -0700
From: Craig James <craig_james@emolecules.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
	rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: Performance Anomaly with "col in (A,B)" vs. "col =
	A OR col = B" ver. 9.0.3
References: 
 <CAPcyiQ1U1k=mcpKT2ecy02Vr=2Eqpee3tnQLpfvW-aViSp=Big@mail.gmail.com>
	<9594.1317056871@sss.pgh.pa.us>
In-Reply-To: <9594.1317056871@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9
X-Spam-Level: 
X-Archive-Number: 201109/370
X-Sequence-Number: 45146

On 9/26/11 10:07 AM, Tom Lane wrote:
> Cranking up the statistics target for the hts_code_id column (and re-ANALYZEing) ought to fix it. If all your tables are this large you might want to just increase default_statistics_target across the board. regards, tom lane 
This is common advice in this forum ....  but what's the down side to increasing statistics?  With so many questions coming to this forum that are due to insufficient statistics, why not just increase the default_statistics_target?  I assume there is a down side, but I've never seen it discussed.  Does it increase planning time?  Analyze time?  Take lots of space?

Thanks,
Craig