Re: KNNGIST next step: adjusting indexAM API

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: KNNGIST next step: adjusting indexAM API
Дата
Msg-id AANLkTimsxO=XA1Yrei9FpZZH5McU_znWiJqo1aF=qoNY@mail.gmail.com
обсуждение исходный текст
Ответ на Re: KNNGIST next step: adjusting indexAM API  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Ответы Re: KNNGIST next step: adjusting indexAM API  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Wed, Dec 1, 2010 at 5:22 AM, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> Lastly, I'm pretty un-thrilled with the way that the KNNGIST patch
>> implements the interface to the opclass-specific hook functions.
>> Seems like it would be cleaner to leave the Consistent function alone
>> and invent a new, separate hook function for processing ORDER BY.
>> Is there a strong reason for having both things done in one call,
>> or was that just done as a byproduct of trying to cram all the data
>> into one ScanKey array?
>
> IIRC, the goal here was to be able to benefit from KNN GiST from
> existing GiST indexes as soon as you restart the server with the new
> code compiled in. I'm not sure it's that important in the context of
> preparing 9.1. It seems that pg_upgrade already has to issue a reindex
> script for GiST indexes.

I don't think Tom was proposing to change the on-disk format, just the API.

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


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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: Proposal: First step towards Intelligent,integrated database
Следующее
От: Robert Haas
Дата:
Сообщение: Re: We really ought to do something about O_DIRECT and data=journalled on ext4