Received: from localhost (unknown [200.46.204.187])
	by postgresql.org (Postfix) with ESMTP id 051239FB314
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 21 Sep 2007 12:47:57 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.187]) (amavisd-maia, port 10024)
	with ESMTP id 28280-04 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 21 Sep 2007 12:47:35 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from mail3.ecircle.de (mail3.ecircle.de [195.140.186.206])
	by postgresql.org (Postfix) with ESMTP id D47119FA443
	for <pgsql-performance@postgresql.org>;
	Fri, 21 Sep 2007 12:47:35 -0300 (ADT)
Received: from einstein.muc.ecircle.de (einstein.muc.ecircle.de [192.168.1.7])
	by mail3.ecircle.de (READY) with ESMTP id E528111C0F1;
	Fri, 21 Sep 2007 17:47:34 +0200 (CEST)
Received: from [192.168.1.91] ([192.168.1.91]) by einstein.muc.ecircle.de with
	Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Sep 2007 17:47:31 +0200
Subject: Re: Searching for the cause of a bad plan
From: Csaba Nagy <nagy@ecircle-ag.com>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: postgres performance list <pgsql-performance@postgresql.org>
In-Reply-To: <1190384799.4661.217.camel@PCD12478>
References: <1190369024.4661.173.camel@PCD12478>
	<1190372365.4202.14.camel@ebony.site>
	<1190374166.4661.194.camel@PCD12478>
	<1190374478.4202.20.camel@ebony.site>
	<1190376744.4661.208.camel@PCD12478>
	<1190381777.4202.50.camel@ebony.site>
	<1190384799.4661.217.camel@PCD12478>
Content-Type: text/plain
Date: Fri, 21 Sep 2007 17:48:09 +0200
Message-Id: <1190389689.4661.220.camel@PCD12478>
Mime-Version: 1.0
X-Mailer: Evolution 2.10.1 
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Sep 2007 15:47:31.0690 (UTC)
	FILETIME=[B893B4A0:01C7FC66]
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200709/368
X-Sequence-Number: 26913

> OK, I can confirm that. I set the statistics target for column "a" on
> table_a to 1000, analyzed, and got the plan below. The only downside is
> that analyze became quite expensive on table_a, it took 15 minutes and
> touched half of the pages... I will experiment with lower settings,
> maybe it will work with less than 1000 too.

So, just to finish this up: setting statistics to 100 worked too, and it
has an acceptable impact on analyze. My original (more complicated)
query is working fine now, with visible effects on server load...

Thanks Simon for your help !

Cheers,
Csaba.