Re: GSoC proposal. Index-only scans for GIST

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: GSoC proposal. Index-only scans for GIST
Дата
Msg-id CA+TgmoZV0WKK5w++awZ6=Q3vEqn=eODUr5i_jz_F12X_fnbDRw@mail.gmail.com
обсуждение исходный текст
Ответ на GSoC proposal. Index-only scans for GIST  (Anastasia Lubennikova <lubennikovaav@gmail.com>)
Ответы Re: GSoC proposal. Index-only scans for GIST  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: GSoC proposal. Index-only scans for GIST  (Anastasia Lubennikova <lubennikovaav@gmail.com>)
Список pgsql-hackers
On Tue, Mar 18, 2014 at 9:12 AM, Anastasia Lubennikova
<lubennikovaav@gmail.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Portability issues in shm_mq
Следующее
От: Tom Lane
Дата:
Сообщение: Re: GSoC proposal. Index-only scans for GIST