Message-ID: <5086F92F.50406@pinpointresearch.com>
Date: Tue, 23 Oct 2012 13:08:15 -0700
From: Steve Crawford <scrawford@pinpointresearch.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: Kevin Grittner <kgrittn@mail.com>
CC: henk de wit <henk53602@hotmail.com>,
 pgsql-performance@postgresql.org
Subject: Re: Query with limit goes from few ms to hours
References: <20121023183316.179560@gmx.com>
In-Reply-To: <20121023183316.179560@gmx.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 10/23/2012 11:33 AM, Kevin Grittner wrote:
> henk de wit wrote:
>
>> Well, what do you know! That did work indeed. Immediately after the
>> ANALYZE on that parent table (taking only a few seconds) a fast
>> plan was created and the query executed in ms again. Silly me, I
>> should have tried that earlier.
> Of course, if your autovacuum settings are aggressive enough, you
> should gernerally not need to run ANALYZE explicitly. You should
> double-check that autovacuum is turned on and configured at least as
> aggressively as the default settings, or you will probably get little
> surprises like this when you least expect them.
>
>
The exception I'd make to Kevin's good advice is for cases when a 
process makes substantial statistics-altering changes to your data (bulk 
insert/delete/update) immediately followed by a query against the 
updated table(s). In those cases there is a good possibility that the 
statistics will not have been automatically updated before the 
subsequent query is planned so an explicit ANALYZE between the update 
and the query can be of value.

Cheers,
Steve