Re: index-only scans

From: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: index-only scans
Date: 2011-10-11 12:16:27
Message-ID: CAPpHfdveVhEoHBou+yiOBUwuwyNU9rXve8d-D_Bdt_6qaPUJbw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 11, 2011 at 2:36 PM, Robert Haas <robertmhaas(at)gmail(dot)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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-10-11 12:23:53 Re: Proposal: casts row to array and array to row
Previous Message Royce Ausburn 2011-10-11 11:55:09 Re: [REVIEW] Patch for cursor calling with named parameters