Re: SELECT DISTINCT very slow - Mailing list pgsql-general

From Greg Stark
Subject Re: SELECT DISTINCT very slow
Date
Msg-id 407d949e0907091736y5855d537g9259ead0df2bf42f@mail.gmail.com
Whole thread Raw
In response to Re: SELECT DISTINCT very slow  (Andres Freund <andres@anarazel.de>)
Responses Re: SELECT DISTINCT very slow
Re: SELECT DISTINCT very slow
List pgsql-general
On Thu, Jul 9, 2009 at 4:47 PM, Andres Freund<andres@anarazel.de> wrote:
> AFAIK the primary cause is that indexes in pg do not store visibility
> information.

Not really. The OP doesn't say how wide the record rows are but unless
they're very wide it wouldn't pay to use an index for this even if you
didn't have to access the heap also. It's going to be faster to scan
the whole heap and either sort or use a hash. Currently there aren't
many cases where a btree with 6,000 copies of 111 distinct keys is
going to be useful.

Arguably the missing feature here is skip-scans where we scan the
index but only pull out one record for each distinct value. I'm not
sure there's anything particularly stopping Postgres from being able
to do them, but it might be a lot of code for a narrow use case.

--
greg
http://mit.edu/~gsstark/resume.pdf

pgsql-general by date:

Previous
From: Scott Marlowe
Date:
Subject: Re: Database storage
Next
From: Tom Lane
Date:
Subject: Re: SELECT DISTINCT very slow