Resultset duplicates (was Re: prefix btree implementation)

Поиск
Список
Период
Сортировка
От Richard Huxton
Тема Resultset duplicates (was Re: prefix btree implementation)
Дата
Msg-id 43443E61.7000709@archonet.com
обсуждение исходный текст
Ответ на Re: prefix btree implementation  ("Qingqing Zhou" <zhouqq@cs.toronto.edu>)
Список pgsql-hackers
Qingqing Zhou wrote:
> Oracle 9 uses the grammar like this:
> 
>     CREATE INDEX ... [ COMPRESS <number_of_first_columns> ]
> 
> So it gives the flexibility of choosing optimal number of coulumns to the 
> user. The script mentioned in the article guesses the optimal number by 
> estimating the size of each choice. But I am thinking we can do it better: 
> (1) we don't require that the compressed number of columns on each page are 
> the same; (2) when we build up index bottom-up, we can determine this number 
> for each page automatically by maximizing the number of items within a page.

Are there any gains in eliminating duplicate values in result-sets? I'd 
guess that many/most large result-sets are sorted which should make it 
possible to get away with a "same as last row" marker when the whole set 
is returned to a client.

Of course, this is where someone turns around and tells me we do this 
already :-)

--  Richard Huxton  Archonet Ltd


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Gaetano Mendola
Дата:
Сообщение: Re: wrong optimization ( postgres 8.0.3 )
Следующее
От: Ron Peacetree
Дата:
Сообщение: Re: [PERFORM] A Better External Sort?