Received: from localhost (maia-4.hub.org [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id D94DF9FB464 for ; Thu, 12 Jul 2007 05:55:15 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 36782-01 for ; Thu, 12 Jul 2007 05:55:10 -0300 (ADT) X-Greylist: delayed 17:26:26.154929 by SQLgrey-1.7.5 Received: from gslimes3.sigma.fr (mx.sigma.fr [195.25.81.244]) by postgresql.org (Postfix) with ESMTP id 1BDE19FB4B9 for ; Thu, 12 Jul 2007 05:55:13 -0300 (ADT) Received: from mercure.sigma.fr (mercure.sigma.fr [195.25.81.9]) by gslimes3.sigma.fr (Postfix) with ESMTP id BC0AD34CEB; Thu, 12 Jul 2007 10:55:08 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mercure.sigma.fr (Postfix) with ESMTP id AD7AC5ED23; Thu, 12 Jul 2007 10:55:08 +0200 (CEST) Received: from mercure.sigma.fr ([127.0.0.1]) by localhost (mercure-1 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24191-96; Thu, 12 Jul 2007 10:55:08 +0200 (CEST) Received: from marc (unknown [192.168.1.1]) by mercure.sigma.fr (Postfix) with ESMTP id 901D43FDBA; Thu, 12 Jul 2007 10:55:08 +0200 (CEST) From: Marc Cousin Organization: Sigma Informatique To: pgsql-performance@postgresql.org Subject: Re: Weird row estimate Date: Thu, 12 Jul 2007 10:55:07 +0200 User-Agent: KMail/1.9.7 Cc: Tom Lane References: <200707111728.43416.mcousin@sigma.fr> <2393.1184186131@sss.pgh.pa.us> In-Reply-To: <2393.1184186131@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200707121055.08230.mcousin@sigma.fr> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200707/136 X-Sequence-Number: 25820 Le Wednesday 11 July 2007 22:35:31 Tom Lane, vous avez =E9crit=A0: > Marc Cousin writes: > > Nevertheless, shouldn't the third estimate be smaller or equal to the s= um > > of the two others ? > > The planner's estimation for subplan conditions is pretty primitive > compared to joinable conditions. When you add the OR, it's no longer > possible to treat the IN like a join, and everything gets an order of > magnitude dumber :-( > > It might be worth trying this as a UNION of the two simple queries. Yes, it's much better on this query with a UNION. The problem is that this is a small set of the query, and there are several= =20 nested IN with an OR condition... But at least now I understand where it=20 comes from. Thanks a lot.