Re: index-only scans

Поиск
Список
Период
Сортировка
От Alexander Korotkov
Тема Re: index-only scans
Дата
Msg-id CAPpHfdveVhEoHBou+yiOBUwuwyNU9rXve8d-D_Bdt_6qaPUJbw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: index-only scans  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Tue, Oct 11, 2011 at 2:36 PM, Robert Haas <robertmhaas@gmail.com> wrote:
Have you given any thought to what would be required to support
index-only scans on non-btree indexes - particularly, GIST?  ISTM we
might have had a thought that some GIST opclasses but not others would
be able to regurgitate tuples, or maybe even that it might vary from
index tuple to index tuple.  But that discussion was a long time ago,
and my memory is fuzzy.
In some GiST opclasses original tuple can't be restored from index tuple. For example, polygon can't be restored from it's MBR. In some opclasses, for example box_ops and point_ops, original tuple can be easily restore from index tuple.
I can't remeber any implementation where this possibility can vary from index tuple to index tuple. GiST opclass for ts_vector have different representation of leaf index tuple depending on it's length. But, at most, it store array of hashes of words, so it's lossy anyway.
I think GiST interface could be extended with optional function which restores original tuple. But there is some additional difficulty, when some opclasses of composite index provide this function, but others - not.

------
With best regards,
Alexander Korotkov. 

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

Предыдущее
От: Royce Ausburn
Дата:
Сообщение: Re: [REVIEW] Patch for cursor calling with named parameters
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Proposal: casts row to array and array to row