Received: from localhost (maia-4.hub.org [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id EE1289FB3D0 for ; Tue, 30 Jan 2007 11:03:20 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-new, port 10024) with ESMTP id 90501-04 for ; Tue, 30 Jan 2007 11:03:06 -0400 (AST) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4 Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by postgresql.org (Postfix) with ESMTP id A72F59FB2FF for ; Tue, 30 Jan 2007 11:03:06 -0400 (AST) Received: by nf-out-0910.google.com with SMTP id x4so227030nfb for ; Tue, 30 Jan 2007 07:03:04 -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:references; b=LlSjAqe4tviABwnFIArnjuHbwP+7szivZxcl+ZtOuZXx/YSJcb6thHpfY5F/y0vVs+umkevWB/lom1qb78jG4y2hOPOO7M3ud2dQXVhU4gLcqMHqeikz17g9SSdnME3x2+4+hmlOMWc/WtOP5xbv9SsglWRcND0pfaX1SmIqV5o= Received: by 10.48.162.15 with SMTP id k15mr907157nfe.1170169383801; Tue, 30 Jan 2007 07:03:03 -0800 (PST) Received: by 10.48.210.4 with HTTP; Tue, 30 Jan 2007 07:03:03 -0800 (PST) Message-ID: <81961ff50701300703r538cfd58o511ef68ee90a90e5@mail.gmail.com> Date: Tue, 30 Jan 2007 10:03:03 -0500 From: "Chad Wagner" To: "Luke Lonergan" Subject: Re: Querying distinct values from a large table Cc: "Simon Riggs" , "Igor Lobanov" , "Richard Huxton" , pgsql-performance@postgresql.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_156949_22193736.1170169383733" References: <81961ff50701300613g25ea4ce6jb357c82fb1ed6733@mail.gmail.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200701/428 X-Sequence-Number: 23029 ------=_Part_156949_22193736.1170169383733 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 1/30/07, Luke Lonergan wrote: > > Not that it helps Igor, but we've implemented single pass sort/unique, > grouping and limit optimizations and it speeds things up to a single > seqscan > over the data, from 2-5 times faster than a typical external sort. Was that integrated back into PostgreSQL, or is that part of Greenplum's offering? I can't think of a way that indexing would help this situation given the > required visibility check of each tuple. > I agree, using indexes as a "skinny" table is a whole other feature that would be nice. -- Chad http://www.postgresqlforums.com/ ------=_Part_156949_22193736.1170169383733 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
On 1/30/07, Luke Lonergan <llonergan@greenplum.com> wrote:
Not that it helps Igor, but we've implemented single pass sort/unique,
grouping and limit optimizations and it speeds things up to a single seqscan
over the data, from 2-5 times faster than a typical external sort.

Was that integrated back into PostgreSQL, or is that part of Greenplum's offering?

I can't think of a way that indexing would help this situation given the
required visibility check of each tuple.

I agree, using indexes as a "skinny" table is a whole other feature that would be nice.


--
Chad
http://www.postgresqlforums.com/ ------=_Part_156949_22193736.1170169383733--