Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cTwLw-0003wH-Ie for pgsql-admin@arkaria.postgresql.org; Wed, 18 Jan 2017 19:57:04 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cTwLw-0000pQ-0s for pgsql-admin@arkaria.postgresql.org; Wed, 18 Jan 2017 19:57:04 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cTwLv-0000pA-Fj for pgsql-admin@postgresql.org; Wed, 18 Jan 2017 19:57:03 +0000 Received: from mail-qt0-x22d.google.com ([2607:f8b0:400d:c0d::22d]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1cTwLs-0007eg-2z for pgsql-admin@postgresql.org; Wed, 18 Jan 2017 19:57:02 +0000 Received: by mail-qt0-x22d.google.com with SMTP id l7so27710286qtd.1 for ; Wed, 18 Jan 2017 11:56:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version; bh=NvLtRf3tH9GqsTH5QDP3/TwQQx56Pm5LMdeCJgSHLP0=; b=mI/7XidD8/5EZVE6r37UECLR19FLeK2l6M0YVukqvWcgQD9FF/mJBD7Iz9KwOC443D X3ob47ZTTppvknmGA1E9nPx+sb26seduFS8TVzrxVd/A0XWQxdRbMdvlmdPzb7qoT3fP 97ZPnG7YCszxULZLncu3ErVktUGeTY1ycRRqB80uDmAS0as9HBHqiwe0tvqamnjqXuKi 7sidkih/egaf/Ie4y0O0Tn1m7iEtBXigJfd7QSnJ74lfx2pezN5H8iio0ztwI5tdTmik tMzeGAo3oT2hcivEYw4yr1RBFMwhw+mFjVoR+BuS/p4sawZcTFIlkUUBdKrauud3zJ6k 46KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=NvLtRf3tH9GqsTH5QDP3/TwQQx56Pm5LMdeCJgSHLP0=; b=c4BVCdyrOXzH/aUuhqY1PlJVi8YqWBzyyksz1+JQ3SmY794vQ9ZYR3GTrfeF2vGpn2 W7AF2lv2lvVpMhgR3j99D5G8tYPhpdvYSn6AfAXbXD2We8oOaxmp4gQ0PaR2BevOHGsy TOfA5Z+D0+iX9oPCAyWFhgzVtea8ExW6hrGF3tqBh8IPW0hn2bKBvaj/zkEzgumZ4yG1 MFQRiKayiWWZlL49xWQmLpCE5ZXbJmGang0iiNZ3BxdnOaLgwR1VxTNBPE+9w+GEMdgO 28JL099yHJRJYCHzJIkNSQyxWiJ2nPpvFvwtkwYtPEPsV4bL4PSFq9DJAoB+7av97Cln 2V3A== X-Gm-Message-State: AIkVDXIzvx9BWOfFFrueVWVNOw+3FKCekm9D+e9ufaBFV/RboFQR2e6COtpK8t/PHKIZKA== X-Received: by 10.200.49.249 with SMTP id i54mr4857972qte.3.1484769418389; Wed, 18 Jan 2017 11:56:58 -0800 (PST) Received: from [192.168.0.9] ([191.190.196.248]) by smtp.gmail.com with ESMTPSA id w75sm1066733qkb.26.2017.01.18.11.56.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Jan 2017 11:56:57 -0800 (PST) To: "pgsql-admin@postgresql.org" From: Clailson Subject: Optimization inner join Message-ID: Date: Wed, 18 Jan 2017 16:56:49 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------A156BFC1D13149C1135522E5" X-Pg-Spam-Score: -2.7 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org This is a multi-part message in MIME format. --------------A156BFC1D13149C1135522E5 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi, Is there something in the roadmap to optimize the inner join? I've this situation above. Table b has 400 rows with null in the column b. explain analyze select * from a inner join b on (b.b = a.a); "Merge Join (cost=0.55..65.30 rows=599 width=16) (actual time=0.030..1.173 rows=599 loops=1)" " Merge Cond: (a.a = b.b)" " -> Index Scan using a_pkey on a (cost=0.28..35.27 rows=1000 width=8) (actual time=0.014..0.364 rows=1000 loops=1)" " -> Index Scan using in01 on b (cost=0.28..33.27 rows=1000 width=8) (actual time=0.012..0.249 rows=600 loops=1)" "Total runtime: 1.248 ms" My question is: Why the planner isn't removing the null rows during the scan of table b? -- Clailson Soares Dinízio de Almeida --------------A156BFC1D13149C1135522E5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi,

Is there something in the roadmap to optimize the inner join?

I've this situation above. Table b has 400 rows with null in the column b.

explain analyze select * from a inner join b on (b.b = a.a);
"Merge Join  (cost=0.55..65.30 rows=599 width=16) (actual time=0.030..1.173 rows=599 loops=1)" 
"  Merge Cond: (a.a = b.b)" 
"  ->  Index Scan using a_pkey on a  (cost=0.28..35.27 rows=1000 width=8) (actual time=0.014..0.364 rows=1000 loops=1)" 
"  ->  Index Scan using in01 on b  (cost=0.28..33.27 rows=1000 width=8) (actual time=0.012..0.249 rows=600 loops=1)" 
"Total runtime: 1.248 ms" 

My question is: Why the planner isn't removing the null rows during the scan of table b?
-- 
Clailson Soares Dinízio de Almeida
--------------A156BFC1D13149C1135522E5--