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 по дате отправления: