Re: prefix btree implementation

Поиск
Список
Период
Сортировка
От Martijn van Oosterhout
Тема Re: prefix btree implementation
Дата
Msg-id 20051006134859.GC10127@svana.org
обсуждение исходный текст
Ответ на Re: prefix btree implementation  (Simon Riggs <simon@2ndquadrant.com>)
Список pgsql-hackers
On Thu, Oct 06, 2005 at 08:53:25AM +0100, Simon Riggs wrote:
> 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.

Well, one thing I would be curious about would be when you index a
multicolumn index, not storing the value of each column in each index
entry? Couldn't there be a btree on the first key, then at the leaf a
pointer to a new btree on the second key, etc.

It would save a lot of space in large multicolumn indexes, no? And
since ctid is an automatic member of each indexkey, it could
automatically remove common key elements.

Codingwise however, it sucks. The whole index_getattr can't happen and
you have remember more state going down. And you probably can't split
the ctid out anyway, because you might end up needing a whole page per
key value then.

Still, I know a large 7 column index where the first three columns
don't change that often and would benefit from this kind of
optimisation.

> 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.

Until we have a better idea about how much functions cost we should be
wary of this. Also, consider if you had an index on sign(x). It's
immutable sure, but useless from a planner prespective for the
optimisation you suggest. How would it know? Presumably there may be
statistics on this but still...

Have a ncie day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

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

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: fixing LISTEN/NOTIFY
Следующее
От: "smile khmer"
Дата:
Сообщение: PG function call