Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1aShXI-0005my-1e for pgsql-performance@arkaria.postgresql.org; Mon, 08 Feb 2016 08:51:08 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1aShXH-0007K1-Hf for pgsql-performance@arkaria.postgresql.org; Mon, 08 Feb 2016 08:51:07 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1aShXG-0007Gq-9E for pgsql-performance@postgresql.org; Mon, 08 Feb 2016 08:51:06 +0000 Received: from mail-wm0-x22c.google.com ([2a00:1450:400c:c09::22c]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1aShX9-0006lJ-1j for pgsql-performance@postgresql.org; Mon, 08 Feb 2016 08:51:05 +0000 Received: by mail-wm0-x22c.google.com with SMTP id 128so145161951wmz.1 for ; Mon, 08 Feb 2016 00:50:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:subject:to:references:cc:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=bZxEIuDLvXP5GWdopRxtQG7V5PWtKHqclZgtLfZ8wWk=; b=pVQjDzcomkU6LUSVNHNKc+2zmnwSfWQY2FSY11HLV+V58HbLJQ/fs48zU80r+LRIv0 qkWxv5B+4+HOGw5kHVSsAzdzwyIkA1gmy4YpzNJLwdMdPYKeO2iZAVPRmMOrHXz/zQ6u kINCs+aVHPQ3ilIRW8/6JSQWy0NU7glUytTn/fR3kjHOZM//PLMpLWDQZvgHKb+XLa5N Ex3xULUELrEs8N60G1oyUSx4A0n5oUOZearzFzsLgf9GRCe1VdH5JvDyH4iMD3e2NBRf 5iS7NK0JOypZLF5Ryzhfhteg/5t5YK1livEKDF17NRTN4n2BypY+6QVOdkN8wx8HARoe 8W5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:subject:to:references:cc:message-id :date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=bZxEIuDLvXP5GWdopRxtQG7V5PWtKHqclZgtLfZ8wWk=; b=hzlV13IdNtQN+E8vSmiuV7/YFKBfdN3ANGBE7ZrydzVecVxg/JNyU0HwEVsJ5NZ6Kr JTqOUUGeyqD/RMEPzZqXoLaiQqBSCHuhgywo30BkpTufhL9oNbIeP76maL3ep4SQLfp+ /OHkmf3Ps6JQVUvkyi8l+X3U4fqBmlqW7D8mAvykgfrrNFW+nSSvWmD1GMVrk4Mr9iwq mpNCvcezkYIdhvYmkhmGlBcvGgzi+IdTga/smL1t49Rt88KncTMLM7Nh/C+xWYWxmrNc 7tW7rIoesx0s6gqXty2ki97QRmpOQroblGERwCAORk7FP23MgHoP84rTnJAr3xsxJjLs ImbA== X-Gm-Message-State: AG10YOT/ELtLnlJPgQiieIekdqo91Ygdac7cRcPt2ji+r2WnV2dsIhahkJDByowVJ87G5Q== X-Received: by 10.194.175.198 with SMTP id cc6mr26578047wjc.24.1454921456425; Mon, 08 Feb 2016 00:50:56 -0800 (PST) Received: from hvlap.hvnet ([89.165.48.131]) by smtp.gmail.com with ESMTPSA id v2sm11494004wmd.24.2016.02.08.00.50.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Feb 2016 00:50:55 -0800 (PST) From: Hedayat Vatankhah Subject: Re: PostgreSQL seems to create inefficient plans in simple conditional joins To: postgres performance list References: <56AD303D.8090800@gmail.com> Cc: David Rowley Message-ID: <56B856E9.8070703@gmail.com> Date: Mon, 8 Feb 2016 12:20:49 +0330 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <56AD303D.8090800@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.7 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org Hi again, /*Hedayat Vatankhah*/ wrote on Sun, 31 Jan 2016 01:20:53 +0330: > Hi, > > /*David Rowley*/ wrote on Sun, 31 Jan 2016 04:57:04 +1300: >> On 31 January 2016 at 01:30, Hedayat Vatankhah >> wrote: >>> Personally, I expect both queries below to perform exactly the same: >>> >>> SELECT >>> t1.id, * >>> FROM >>> t1 >>> INNER JOIN >>> t2 ON t1.id = t2.id >>> where t1.id > -9223372036513411363; >>> >>> And: >>> >>> SELECT >>> t1.id, * >>> FROM >>> t1 >>> INNER JOIN >>> t2 ON t1.id = t2.id >>> where t1.id > -9223372036513411363 and t2.id > >>> -9223372036513411363; >>> >>> Unfortunately, they do not. PostgreSQL creates different plans for >>> these >>> queries, which results in very poor performance for the first one >>> compared >>> to the second (What I'm testing against is a DB with around 350 million >>> rows in t1, and slightly less in t2). >>> >>> EXPLAIN output: >>> First query: http://explain.depesz.com/s/uauk >>> Second query: link: http://explain.depesz.com/s/uQd >> Yes, unfortunately you've done about the only thing that you can do, >> and that's just include both conditions in the query. Is there some >> special reason why you can't just write the t2.id > ... condition in >> the query too? or is the query generated dynamically by some software >> that you have no control over? I just found another issue with using a query like the second one (using LEFT JOINs instead of INNER JOINs): referencing id columns of joined tables explicitly disables PostgreSQL join removal optimization when you only select column(s) from t1! :( I should forget about creating views on top of JOIN queries, and build appropriate JOIN queries with referenced table and appropriate conditions manually, so the whole data model should be exposed to the application. If I'm not wrong, PostgreSQL should understand that ANY condition on t2 doesn't change the LEFT JOIN output when t2 columns are not SELECTed. Regards, Hedayat -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance