Re: Performance Anomaly with "col in (A,B)" vs. "col = A OR col = B" ver. 9.0.3 - Mailing list pgsql-performance

From Tom Lane
Subject Re: Performance Anomaly with "col in (A,B)" vs. "col = A OR col = B" ver. 9.0.3
Date
Msg-id 10130.1317058511@sss.pgh.pa.us
Whole thread Raw
In response to Re: Performance Anomaly with "col in (A,B)" vs. "col = A OR col = B" ver. 9.0.3  (Craig James <craig_james@emolecules.com>)
Responses Re: Performance Anomaly with "col in (A,B)" vs. "col = A OR col = B" ver. 9.0.3
List pgsql-performance
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
arethis 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
comingto this forum that are due to insufficient statistics, why not just increase the default_statistics_target?  I
assumethere is a down side, but I've never seen it discussed.  Does it increase planning time?  Analyze time?  Take
lotsof 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

pgsql-performance by date:

Previous
From: Craig James
Date:
Subject: Re: Performance Anomaly with "col in (A,B)" vs. "col = A OR col = B" ver. 9.0.3
Next
From: Marti Raudsepp
Date:
Subject: Re: [PERFORMANCE] Insights: fseek OR read_cluster?