Re: GSoC proposal. Index-only scans for GIST

Поиск
Список
Период
Сортировка
От Anastasia Lubennikova
Тема Re: GSoC proposal. Index-only scans for GIST
Дата
Msg-id CAP4vRV62m4m9q-HJ=mnQbT5yAKjzqFvc1dAsrAvGjXWXC7sW3g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: GSoC proposal. Index-only scans for GIST  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: [PATCH] Negative Transition Aggregate Functions (WIP)
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Only first XLogRecData is visible to rm_desc with WAL_DEBUG