From: Tom Lane <tgl@sss.pgh.pa.us>
To: Craig James <craig_james@emolecules.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Performance Anomaly with "col in (A, B)" vs. "col = A OR col = B" ver. 9.0.3
Date: Mon, 26 Sep 2011 13:35:11 -0400
Message-ID: <10130.1317058511@sss.pgh.pa.us> (raw)
In-Reply-To: <4E80B3F9.8070001@emolecules.com>
References: <CAPcyiQ1U1k=mcpKT2ecy02Vr=2Eqpee3tnQLpfvW-aViSp=Big@mail.gmail.com>
<9594.1317056871@sss.pgh.pa.us>
<4E80B3F9.8070001@emolecules.com>
Craig James <craig_james@emolecules.com> writes:
> 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?
Yes, yes, and yes. We already did crank up the default
default_statistics_target once (in 8.4), so I'm hesitant to do it again.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, craig_james@emolecules.com
Subject: Re: Performance Anomaly with "col in (A, B)" vs. "col = A OR col = B" ver. 9.0.3
In-Reply-To: <10130.1317058511@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox