On Thu, Jul 9, 2009 at 4:47 PM, Andres Freund<andres@xxxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
