Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229])
	by mail.postgresql.org (Postfix) with ESMTP id E79231C7037C
	for <pgsql-performance@postgresql.org>;
	Tue, 13 Dec 2011 18:13:29 -0400 (AST)
Received: from [2404:130:0:10::40:2] (helo=mail.catalyst.net.nz)
	by magus.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <mark.kirkwood@catalyst.net.nz>) id 1RaabH-0006Ca-Pb
	for pgsql-performance@postgresql.org; Tue, 13 Dec 2011 22:13:29 +0000
Received: from localhost (localhost [127.0.0.1])
	by mail.catalyst.net.nz (Postfix) with ESMTP id 71BBD32A6B;
	Wed, 14 Dec 2011 11:13:12 +1300 (NZDT)
X-Virus-Scanned: Debian amavisd-new at catalyst.net.nz
Received: from mail.catalyst.net.nz ([127.0.0.1])
	by localhost (bertrand.catalyst.net.nz [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id zCx5YMnpxrdD; Wed, 14 Dec 2011 11:13:11 +1300 (NZDT)
Received: from [IPv6:2404:130:0:1000:222:15ff:fe5c:2471] (unknown
	[IPv6:2404:130:0:1000:222:15ff:fe5c:2471])
	(Authenticated sender: mark.kirkwood)
	by mail.catalyst.net.nz (Postfix) with ESMTPSA id EB3063200F;
	Wed, 14 Dec 2011 11:13:11 +1300 (NZDT)
Message-ID: <4EE7CDEF.1040709@catalyst.net.nz>
Date: Wed, 14 Dec 2011 11:13:03 +1300
From: Mark Kirkwood <mark.kirkwood@catalyst.net.nz>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
CC: kaloyan@digsys.bg
Subject: Re: Slow query after upgrade from 8.2 to 8.4
References: <4EE0F3F4.8040909@digsys.bg> <14557.1323401295@sss.pgh.pa.us>
	<4EE1FDC7.70601@digsys.bg> <27472.1323444617@sss.pgh.pa.us>
In-Reply-To: <27472.1323444617@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Host-Lookup-Failed: Reverse DNS lookup failed for 2404:130:0:10::40:2
	(failed)
X-Pg-Spam-Score: 0.3 (/)
X-Archive-Number: 201112/105
X-Sequence-Number: 45904

On 10/12/11 04:30, Tom Lane wrote:
> However, it's not apparent to me why you would see any difference 
> between 8.2 and 8.4 on this type of query. I tried a query analogous 
> to this one on both, and got identical plans. I'm guessing that your 
> slowdown is due to not having updated statistics on the new 
> installation, or perhaps failing to duplicate some relevant settings.

I notice he has 8.4.*8*... I wonder if he's running into the poor 
estimation bug for sub-selects/semi joins that was fixed in 8.4.9.

Kaloyan, can you try the query in 8.4.9?

regards

Mark