Re: prefix btree implementation

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: prefix btree implementation
Дата
Msg-id 1128585205.3738.31.camel@localhost.localdomain
обсуждение исходный текст
Ответ на Re: prefix btree implementation  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: prefix btree implementation  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: prefix btree implementation  (Martijn van Oosterhout <kleptog@svana.org>)
Список pgsql-hackers
On Wed, 2005-10-05 at 00:50 -0400, Tom Lane wrote:
> Qingqing Zhou <zhouqq@cs.toronto.edu> writes:
> > 1/ What types of prefix compression shall we support?
> 
> Given the requirement of datatype independence, this idea seems a
> complete nonstarter to me...

It would be possible to compress on similar values, since we know the
output of the comparison in the final stage of the sort of the index
build. That wouldn't need to rely upon anything to do with the datatype,
since "they are equal" is a fact outside the encapsulation, and is
arrived at by use of the datatype's own comparison logic.

But that isn't prefix compression, just compression.

But why do we want this? Its very easy to work out a data-aware
prefixing or compression scheme and then encapulate that in a function.
The function can then be used in a functional index and the usage hidden
behind a view.

It might be worth teaching the optimiser that if it has an index on an
immutable function that if we have WHERE x = k and a functional index on
f(x) then we can access the functional index with 
f(x) = f(k), as long as we also reapply the original WHERE clause. 

Best Regards, Simon Riggs




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

Предыдущее
От: "Pavel Stehule"
Дата:
Сообщение: Re: current_user versus current_role SOLVED
Следующее
От: Dmitry Karasik
Дата:
Сообщение: Re: prepared queries in plperl