Re: index-only scans - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: index-only scans
Date
Msg-id CAPpHfdveVhEoHBou+yiOBUwuwyNU9rXve8d-D_Bdt_6qaPUJbw@mail.gmail.com
Whole thread Raw
In response to Re: index-only scans  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: Royce Ausburn
Date:
Subject: Re: [REVIEW] Patch for cursor calling with named parameters
Next
From: Robert Haas
Date:
Subject: Re: Proposal: casts row to array and array to row