Received: from localhost (maia-5.hub.org [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id E14049FB973 for ; Tue, 13 Feb 2007 15:17:11 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-new, port 10024) with ESMTP id 66535-01 for ; Tue, 13 Feb 2007 15:16:58 -0400 (AST) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4 Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by postgresql.org (Postfix) with ESMTP id 5F9BB9FB855 for ; Tue, 13 Feb 2007 15:16:59 -0400 (AST) Received: by ug-out-1314.google.com with SMTP id k3so1679848ugf for ; Tue, 13 Feb 2007 11:16:55 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mB5f7XPt1bV7AuNmCexBOla8WVK2juRMcY8clWXoBqybqa8h9/xSR+uUmezgb9JMbAuBeE+57FagvKN1jFeDJtMsmPuElBkqQOpbvLe5dkEWX7s/Wb18z2bWy5ZdfU6wU61WDNKvtoR/1oI6daaYzC9gmDCJrmbx91ZbgdeVhlM= Received: by 10.78.179.12 with SMTP id b12mr114791huf.1171394214364; Tue, 13 Feb 2007 11:16:54 -0800 (PST) Received: by 10.78.35.18 with HTTP; Tue, 13 Feb 2007 11:16:54 -0800 (PST) Message-ID: Date: Tue, 13 Feb 2007 14:16:54 -0500 From: "Merlin Moncure" To: pgsql-performance@nullmx.com Subject: Re: JOIN to a VIEW makes a real slow query Cc: pgsql-performance@postgresql.org In-Reply-To: <200702131253.55486.pgsql-performance@nullmx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200702131253.55486.pgsql-performance@nullmx.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200702/134 X-Sequence-Number: 23188 On 2/13/07, Chuck D. wrote: > Hi folks, > > I don't know if this is an SQL or PERFORMANCE list problem but I wanted to > check here first. I've seen this discussed on the list before but I'm still > not sure of the solution. Maybe my query is just structured wrong. > > I recently visited an old project of mine that has a 'city', 'state,' > and 'country' tables. The city data comes from multiple sources and totals > about 3 million rows. I decided to split the city table up based on the > source (world_city, us_city). This makes easier updating because the > assigned feature id's from the two sources overlap in some cases making it > impossible to update as a single merged table. > > However, I decided to create a view to behave like the old 'city' table. The > view is just a simple: > > SELECT [columns] > FROM world_city > UNION > SELECT [columns] > FROM us_city > ; > > Selecting from the view is very quick, but JOINing to the view is slow. About > 65 seconds to select a city. It doesn't matter wether it is joined to one > table or 6 like it is in my user_detail query - it is still slow. It has > indexes on the city_id, state_id, country_id of each table in the view too. > Everything has been 'VACUUM ANALYZE' ed. use 'union all' instead of union. union without all has an implied sort and duplicate removal step that has to be resolved, materializing the view, before you can join to it. merlin