Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YXf1S-0004iK-T3 for pgsql-performance@arkaria.postgresql.org; Tue, 17 Mar 2015 00:06:15 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YXf1S-00010H-2S for pgsql-performance@arkaria.postgresql.org; Tue, 17 Mar 2015 00:06:14 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YXf1Q-000109-P8 for pgsql-performance@postgresql.org; Tue, 17 Mar 2015 00:06:12 +0000 Received: from mail-by2on0694.outbound.protection.outlook.com ([2a01:111:f400:fc0c::694] helo=na01-by2-obe.outbound.protection.outlook.com) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YXf1L-0001LZ-6f for pgsql-performance@postgresql.org; Tue, 17 Mar 2015 00:06:11 +0000 Received: from BN3PR11MB0337.namprd11.prod.outlook.com (25.161.220.19) by BN3PR11MB0243.namprd11.prod.outlook.com (25.161.220.139) with Microsoft SMTP Server (TLS) id 15.1.112.19; Tue, 17 Mar 2015 00:05:59 +0000 Received: from decina.attlocal.net (2602:306:ce8b:3460:bc26:f347:3a6e:b9f2) by BN3PR11MB0337.namprd11.prod.outlook.com (25.161.220.19) with Microsoft SMTP Server (TLS) id 15.1.112.19; Tue, 17 Mar 2015 00:05:55 +0000 Message-ID: <55076FFB.9090105@BlueTreble.com> Date: Mon, 16 Mar 2015 19:06:19 -0500 From: Jim Nasby User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Tomas Vondra , , Scott Marlowe , Varadharajan Mukundan CC: Subject: Re: Performance issues References: <84a6fe4be04c3ef0a714851977860ac8@mail.gmail.com> <160b8780d89add7f23c4eb9c3debb99d@mail.gmail.com> <55034A48.4040409@2ndquadrant.com> <849e75d9463938372dd4c516f5c5d89c@mail.gmail.com> <55037CEA.5050906@2ndquadrant.com> <55073272.20209@BlueTreble.com> <55074424.9050506@2ndquadrant.com> In-Reply-To: <55074424.9050506@2ndquadrant.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [2602:306:ce8b:3460:bc26:f347:3a6e:b9f2] X-ClientProxiedBy: CY1PR00CA0030.namprd00.prod.outlook.com (25.160.142.168) To BN3PR11MB0337.namprd11.prod.outlook.com (25.161.220.19) Authentication-Results: postgresql.org; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN3PR11MB0337; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN3PR11MB0243; X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(377454003)(51704005)(479174004)(24454002)(80316001)(33656002)(19580395003)(19580405001)(64126003)(86362001)(36756003)(50466002)(87976001)(40100003)(46102003)(47776003)(23746002)(93886004)(65806001)(122386002)(65956001)(50986999)(54356999)(65816999)(15975445007)(87266999)(76176999)(99136001)(53416004)(92566002)(42186005)(62966003)(83506001)(77156002)(2950100001)(3826002)(85282002)(336755003)(18886065003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR11MB0337; H:decina.attlocal.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BN3PR11MB0337; BCL:0; PCL:0; RULEID:; SRVR:BN3PR11MB0337; X-Forefront-PRVS: 0518EEFB48 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Mar 2015 00:05:55.4894 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR11MB0337 X-OriginatorOrg: bluetreble.com X-Pg-Spam-Score: -1.9 (-) 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 On 3/16/15 3:59 PM, Tomas Vondra wrote: > On 16.3.2015 20:43, Jim Nasby wrote: >> On 3/13/15 7:12 PM, Tomas Vondra wrote: >>> (4) I suspect many of the relations referenced in the views are not >>> actually needed in the query, i.e. the join is performed but >>> then it's just discarded because those columns are not used. >>> Try to simplify the views as much has possible - remove all the >>> tables that are not really necessary to run the query. If two >>> queries need different tables, maybe defining two views is >>> a better approach. >> >> A better alternative with multi-purpose views is to use an outer >> join instead of an inner join. With an outer join if you ultimately >> don't refer to any of the columns in a particular table Postgres will >> remove the table from the query completely. > > Really? Because a quick test suggests otherwise: > > db=# create table test_a (id int); > CREATE TABLE > db=# create table test_b (id int); > CREATE TABLE > db=# explain select test_a.* from test_a left join test_b using (id); > QUERY PLAN > ---------------------------------------------------------------------- > Merge Left Join (cost=359.57..860.00 rows=32512 width=4) > Merge Cond: (test_a.id = test_b.id) > -> Sort (cost=179.78..186.16 rows=2550 width=4) > Sort Key: test_a.id > -> Seq Scan on test_a (cost=0.00..35.50 rows=2550 width=4) > -> Sort (cost=179.78..186.16 rows=2550 width=4) > Sort Key: test_b.id > -> Seq Scan on test_b (cost=0.00..35.50 rows=2550 width=4) > (8 rows) > > Also, how would that work with duplicate rows in the referenced table? Right, I neglected to mention that the omitted table must also be unique on the join key: decibel@decina.attlocal=# create table a(a_id serial primary key); CREATE TABLE decibel@decina.attlocal=# create table b(a_id int); CREATE TABLE decibel@decina.attlocal=# explain analyze select a.* from a left join b using(a_id); QUERY PLAN ----------------------------------------------------------------------------------------------------------- Hash Right Join (cost=67.38..137.94 rows=2550 width=4) (actual time=0.035..0.035 rows=0 loops=1) Hash Cond: (b.a_id = a.a_id) -> Seq Scan on b (cost=0.00..35.50 rows=2550 width=4) (never executed) -> Hash (cost=35.50..35.50 rows=2550 width=4) (actual time=0.002..0.002 rows=0 loops=1) Buckets: 4096 Batches: 1 Memory Usage: 32kB -> Seq Scan on a (cost=0.00..35.50 rows=2550 width=4) (actual time=0.001..0.001 rows=0 loops=1) Planning time: 0.380 ms Execution time: 0.086 ms (8 rows) decibel@decina.attlocal=# alter table b add primary key(a_id); ALTER TABLE decibel@decina.attlocal=# explain analyze select a.* from a left join b using(a_id); QUERY PLAN ----------------------------------------------------------------------------------------------- Seq Scan on a (cost=0.00..35.50 rows=2550 width=4) (actual time=0.001..0.001 rows=0 loops=1) Planning time: 0.247 ms Execution time: 0.029 ms (3 rows) decibel@decina.attlocal=# alter table a drop constraint a_pkey; ALTER TABLE decibel@decina.attlocal=# explain analyze select a.* from a left join b using(a_id); QUERY PLAN ----------------------------------------------------------------------------------------------- Seq Scan on a (cost=0.00..35.50 rows=2550 width=4) (actual time=0.001..0.001 rows=0 loops=1) Planning time: 0.098 ms Execution time: 0.011 ms (3 rows) -- Jim Nasby, Data Architect, Blue Treble Consulting Data in Trouble? Get it in Treble! http://BlueTreble.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance