Re: [RFC] Minmax indexes

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: [RFC] Minmax indexes
Дата
Msg-id CA+U5nMKy7C6gye1mN6m36f8dj97rc8drHiQuy53Ja+3_=rYYEQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [RFC] Minmax indexes  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 15 June 2013 00:07, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> We've talked a lot about index-organized tables in the past.  How much
> of the use case for this would be subsumed by a feature like that?

IOTs would only work for one specific organisation, acting like a
multi-column btree. So you could use IOTs for this but only in a
limited way.

MinMax indexes cover multiple columns, possibly even all columns if
desired. So MMIs have much greater usefulness, as well as not
requiring a full reload of the data when you decide you want one.

Personally, I think IOTs are not worth pursuing. IOTs for Postgres
would require major changes to the definition of the heap, so we're a
long way from implementing them directly and coping with all of the
detailed implementation horrors. Grouped Item Tuple indexes are
theoretically equivalent in terms of size and number of block accesses
required to access data. Heikki's earlier work on that could easily be
revived. IOTs would be a multi-year effort with conflicting use cases.

Note that SQLServer and Sybase use block range indexes for primary
indexes, neatly avoiding the hassle Oracle walked into when they chose
to do IOTs. I think we should learn that same lession ourselves.

--Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: stray SIGALRM
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [RFC] Minmax indexes