Message-ID: <4C4D5BE9.6040808@postnewspapers.com.au>
Date: Mon, 26 Jul 2010 17:56:57 +0800
From: Craig Ringer <craig@postnewspapers.com.au>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: Vitalii Tymchyshyn <tivv00@gmail.com>
CC: pgsql-performance@postgresql.org
Subject: Re: Big difference in time returned by EXPLAIN ANALYZE
	SELECT ... AND 	SELECT ...
References: <AANLkTinHPkEDijSHbxY3KxygO2SWy6XMPLvn=CvnWdG8@mail.gmail.com>
	<4C4D5220.9010101@postnewspapers.com.au> <4C4D547E.50905@gmail.com>
In-Reply-To: <4C4D547E.50905@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 26/07/10 17:25, Vitalii Tymchyshyn wrote:
> 26.07.10 12:15, Craig Ringer написав(ла):
>> On 26/07/10 16:35, Piotr Gasidło wrote:
>>   
>>> Hello,
>>>
>>> I've found strange problem in my database (8.4.4, but also 9.0beta3,
>>> default postgresql.conf, shared_buffers raised to 256MB).
>>>
>>> EXPLAIN ANALYZE SELECT ...
>>> Total runtime: 4.782 ms
>>> Time: 25,970 ms

>> Given that, I'm wondering if the difference in this case is planning
>> time. I can't really imagine the query planner taking 20 seconds (!!) to
>> run, though, no matter how horrifyingly complicated the query and table
>> structure were, unless there was something going wrong.
>>    
> Actually it's 20ms, so I suspect your point about planning time is correct.

Oh, a commas-as-fraction-separator locale.

That makes sense. Thanks for the catch.

--
Craig Ringer