Re: GSoC proposal. Index-only scans for GIST - Mailing list pgsql-hackers

From Anastasia Lubennikova
Subject Re: GSoC proposal. Index-only scans for GIST
Date
Msg-id CAP4vRV62m4m9q-HJ=mnQbT5yAKjzqFvc1dAsrAvGjXWXC7sW3g@mail.gmail.com
Whole thread Raw
In response to Re: GSoC proposal. Index-only scans for GIST  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
2014-03-18 18:47 GMT+04:00 Robert Haas <robertmhaas@gmail.com>

> 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?
 
 I meant Datum that storages in Gist-tree nodes. Now gistgettuple() returns xs_ctup.t_self (item pointer). I'm going to add index-only scan functionality: gistsettuple() will return pointer and Datum itself as xs_itup . So queue will contain both the pointer and the Datum. If visibilitymap_test returns true then Datum from xs_itup would be added into queue. Otherwise page must be scanned.

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?
 
about amcanreturn:
I'm going to create function gistcanreturn() = If fetch() is defined for all indexed columns?

And last point of my project is to implement fetch() for existing opclasses based on GIST.

--
Best regards,
Lubennikova Anastasia

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: [PATCH] Negative Transition Aggregate Functions (WIP)
Next
From: Alvaro Herrera
Date:
Subject: Re: Only first XLogRecData is visible to rm_desc with WAL_DEBUG