X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id C514A53A60 for ; Tue, 29 Mar 2005 15:13:51 +0100 (BST) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 57972-03 for ; Tue, 29 Mar 2005 14:13:41 +0000 (GMT) Received: from web1-glo.biscit.net (web1-glo.biscit.net [82.195.96.53]) by svr1.postgresql.org (Postfix) with ESMTP id 7E7AC5347C for ; Tue, 29 Mar 2005 15:13:40 +0100 (BST) Received: from bolek.coachhouse (host62-7-155-87.webport.bt.net [62.7.155.87]) by web1-glo.biscit.net (8.10.2/8.10.2) with ESMTP id j2TEDUA03090; Tue, 29 Mar 2005 15:13:31 +0100 Received: (Exim 3.36) #1 (Debian)) protocol: esmtp id 1DGHSD-00022h-00 ; Tue, 29 Mar 2005 15:12:25 +0100 Message-ID: <42496248.4080407@numerixtechnology.de> Date: Tue, 29 Mar 2005 15:12:24 +0100 From: T E Schmitz Reply-To: mailreg@numerixtechnology.de User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alvaro Herrera Cc: pgsql-sql@postgresql.org Subject: Re: cost of CREATE VIEW ... AS SELECT DISTINCT References: <42487A6D.6020506@numerixtechnology.de> <1112047463.22988.25.camel@state.g2switchworks.com> <424928D8.7060705@numerixtechnology.de> <20050329132941.GA27251@wolff.to> <4249564B.1000807@numerixtechnology.de> <20050329135823.GA23852@dcc.uchile.cl> In-Reply-To: <20050329135823.GA23852@dcc.uchile.cl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.248 tagged_above=0 required=5 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: X-Archive-Number: 200503/378 X-Sequence-Number: 20857 Alvaro Herrera wrote: > On Tue, Mar 29, 2005 at 02:21:15PM +0100, T E Schmitz wrote: > >>Bruno Wolff III wrote: >> >>>On Tue, Mar 29, 2005 at 11:07:20 +0100, >>> T E Schmitz wrote: >>> >>> >>>>Would the "SELECT DISTINCT origin" always cause a sequential table >>>>scan regardless whether there is an index on the origin column or >>>>not? >>> >>>It's worse than that, SELECT DISTINCT cannot use a hash aggregate >>>plan and will need to do a sort to eliminate duplicates. Unless the >>>view is used in a way that restricts the candidate rows, this >>>probably isn't going to be very fast. You might be better off >>>changing the view to use GROUP BY instead of DISTINCT. >> >>As far as I can see (via EXPLAIN), both DISTINCT and GROUP BY will >>lead to a sequentail scan. Is that correct? > > That (GROUP BY using a seqscan) may be caused by the small size of the > table. Try populating it some more. > Shall do. But am I correct in assuming that I should place an index on the group by (TRANSAKTION.ORIGIN) column? -- Regards/Gruß, Tarlika Elisabeth Schmitz