Received: from maia.hub.org (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id AD0D363457B for ; Fri, 16 Apr 2010 05:31:17 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 26180-06-4 for ; Fri, 16 Apr 2010 08:31:01 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by mail.postgresql.org (Postfix) with ESMTP id 438E8634DBA for ; Fri, 16 Apr 2010 05:31:00 -0300 (ADT) Received: by ey-out-2122.google.com with SMTP id d26so141463eyd.33 for ; Fri, 16 Apr 2010 01:30:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=vjZdVK2d0SxJIbcvjYWTUMKyq2roRdoZPQZzZA8zK1s=; b=ge46BUv+sx4IprClDCDxf6wfAHSlsBJYzAzUG5bbUjgk3cL6jLd2w0+U7bZN/w9pDr 5POVHZ0NSN/vtbNpnKYFVH0WAORDWoar5tPTFr4ZfGzK0N0JHaQEfcIyGzTJ5ck4sjK9 R1hWoUOOF24EgTZbgX9kBDxvwHB6voGMQXqaY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=m1Ns96+KrOQ9Qch+EawtT23cp4CtzzcC8mi+QehuRwFb0lhS7tqMpA+eOIRvfkwa0u WhCSmz9H9OVJjwivKAZi2YBGOVF4G6uTgFfdXlZRSAHh4daqQg9DL0bAwG7eclSgFBPX 28b+qDYLMBtYnzIZqSwJ1Ow2U6VsNLLExojKg= Received: by 10.213.44.67 with SMTP id z3mr635430ebe.57.1271406658620; Fri, 16 Apr 2010 01:30:58 -0700 (PDT) Received: from [0.0.0.0] (5357DA75.cable.casema.nl [83.87.218.117]) by mx.google.com with ESMTPS id 15sm1552388ewy.4.2010.04.16.01.30.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 16 Apr 2010 01:30:58 -0700 (PDT) Message-ID: <4BC8204A.7050904@gmail.com> Date: Fri, 16 Apr 2010 10:31:06 +0200 From: Yeb Havinga User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: =?UTF-8?B?0JLRltGC0LDQu9GW0Lkg0KLQuNC80YfQuNGI0LjQvQ==?= CC: pgsql-performance@postgresql.org Subject: Re: Planner not using column limit specified for one column for another column equal to first References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-0.524 tagged_above=-10 required=5 tests=AWL=-1.324, BAYES_50=0.8 X-Spam-Level: X-Archive-Number: 201004/199 X-Sequence-Number: 38449 Віталій Тимчишин wrote: > Hello. > > I have a query that performs very poor because there is a limit on > join column that is not applied to other columns: > > select * from company this_ left outer join company_tag this_1_ on > this_.id=this_1_.company_id left outer join company_measures > companymea2_ on this_.id=companymea2_.company_id left outer join > company_descr ces3_ on this_.id=ces3_.company_id where this_1_.tag_id > = 7 and this_.id>50000000 > and this_1_.company_id>50000000 > order by this_.id asc limit 1000; > > (plan1.txt) > Total runtime: 7794.692 ms > > At the same time if I apply the limit (>50000000) to other columns in > query itself it works like a charm: > > select * from company this_ left outer join company_tag this_1_ on > this_.id=this_1_.company_id left outer join company_measures > companymea2_ on this_.id=companymea2_.company_id left outer join > company_descr ces3_ on this_.id=ces3_.company_id where this_1_.tag_id > = 7 and this_.id>50000000 > and this_1_.company_id>50000000 > and companymea2_.company_id>50000000 and ces3_.company_id>50000000 > order by this_.id asc limit 1000; > > (plan2.txt) > Total runtime: 27.547 ms > > I've thought and someone in this list've told me that this should be > done automatically. Yes, if you have in a query a=b and b=c, then the optimizer figures out that a=c as well. (a,b and c are then member of the same equivalence class). However both queries are not the same, since the joins you're using are outer joins. In the first it's possible that records are returned for company records with no matching ces3_ records, the ces3_ records is null in that case. In the second query no NULL ces3_ information may be returned. Another thing is it seems that the number of rows guessed is far off from the actual number of rows, is the number 5000000 artificial or are you're statistics old or too small histogram/mcv's? regards, Yeb Havinga