Re: GSoC proposal. Index-only scans for GIST

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Anastasia Lubennikova <lubennikovaav(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: GSoC proposal. Index-only scans for GIST
Date: 2014-03-18 14:47:33
Message-ID: CA+TgmoZV0WKK5w++awZ6=Q3vEqn=eODUr5i_jz_F12X_fnbDRw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 18, 2014 at 9:12 AM, Anastasia Lubennikova
<lubennikovaav(at)gmail(dot)com> wrote:
> Support for index-only scans for GIST index

This is a cool idea, if it can be made to work.

> If the fetch() is specified by the developer, then using it, algorithm can
> retrieve the data directly to output areas at this stage, without reference
> to the heap.

This seems to be the crux of your proposal, but it seems vague: what
exactly do you mean by "retrieve the data directly to output areas"?
What data are you going to retrieve and where are you going to put it?

Another question to consider is: which operator classes do you
anticipate that this will work for and which ones do you anticipate
that it will not work for? Any operator class that lossifies that
input data before storing it in the index is presumably doomed, but
which ones do that, and which do not?

Tom Lane previously proposed extending SP-GiST to support index-only
scans. You might find that discussing worth reading, or perhaps
consider it as an alternative if GiST doesn't work out:

http://www.postgresql.org/message-id/10839.1323885644@sss.pgh.pa.us

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-03-18 15:07:17 Re: GSoC proposal. Index-only scans for GIST
Previous Message Tom Lane 2014-03-18 14:44:08 Re: Portability issues in shm_mq