Re: SELECT DISTINCT very slow

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: SELECT DISTINCT very slow
Дата
Msg-id 407d949e0907091736y5855d537g9259ead0df2bf42f@mail.gmail.com
обсуждение исходный текст
Ответ на Re: SELECT DISTINCT very slow  (Andres Freund <andres@anarazel.de>)
Ответы Re: SELECT DISTINCT very slow
Re: SELECT DISTINCT very slow
Список 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 по дате отправления:

Предыдущее
От: Scott Marlowe
Дата:
Сообщение: Re: Database storage
Следующее
От: Tom Lane
Дата:
Сообщение: Re: SELECT DISTINCT very slow