Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id EA3529F9588 for ; Thu, 1 Nov 2007 11:21:33 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 98716-04 for ; Thu, 1 Nov 2007 11:21:14 -0300 (ADT) X-Greylist: whitelisted by SQLgrey-1.7.5 Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by postgresql.org (Postfix) with ESMTP id 344189F949A for ; Thu, 1 Nov 2007 11:21:20 -0300 (ADT) Received: from smtp3-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp3-g19.free.fr (Postfix) with ESMTP id CDF7617B592; Thu, 1 Nov 2007 15:21:18 +0100 (CET) Received: from [192.168.0.1] (ra178-1-88-163-20-163.fbx.proxad.net [88.163.20.163]) by smtp3-g19.free.fr (Postfix) with ESMTP id 7E81D17B562; Thu, 1 Nov 2007 15:21:18 +0100 (CET) Subject: Re: [Fwd: Re: Outer joins and Seq scans] From: Sami Dalouche To: Tom Lane Cc: pgsql-performance In-Reply-To: <4121.1193923796@sss.pgh.pa.us> References: <1193865739.23774.2.camel@samlaptop> <1193910660.29867.3.camel@samlaptop> <4121.1193923796@sss.pgh.pa.us> Content-Type: text/plain; charset=utf-8 Date: Thu, 01 Nov 2007 15:21:17 +0100 Message-Id: <1193926878.31606.4.camel@samlaptop> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200711/14 X-Sequence-Number: 27429 Thanks for your answer. So, basically, what you are saying is that there is nothing particularly wrong with the query, nor with its optimization ? So if I need performance for this query, I should just revert to other techniques (giving more memory to postgres, caching outside postgres, etc..) ? Regards, Sami Dalouche Le jeudi 01 novembre 2007 à 09:29 -0400, Tom Lane a écrit : > Sami Dalouche writes: > > Compare that to the following query, that is exactly the same except > > that the City table is inner'joined instead of outer joined > > ... > > the explain analyze is available at : > > http://www.photosdesami.com/temp/exp6.txt > > AFAICS it's just absolutely blind luck that that query is fast. The > planner chooses to do the contactinf7_/city8_ join first, and because > that happens to return no rows at all, all the rest of the query falls > out in no time, even managing to avoid the scan of adcreatedevent. > If there were any rows out of that join it would be a great deal slower. > > There is a pretty significant semantic difference between the two > queries, too, now that I look closer: when you make > "... join City city8_ on contactinf7_.city_id=city8_.id" > a plain join instead of left join, that means the join to contactinf7_ > can be reduced to a plain join as well, because no rows with nulls for > contactinf7_ could possibly contribute to the upper join's result. > That optimization doesn't apply in the original form of the query, > which restricts the planner's freedom to rearrange things. > > regards, tom lane