Skip site navigation (1) Skip section navigation (2)

Re: KNNGIST next step: adjusting indexAM API

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: KNNGIST next step: adjusting indexAM API
Date: 2010-12-01 15:36:50
Message-ID: 16286.1291217810@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> Right, AFAIK there is nothing in KNNGIST that would involve an on-disk
>> data change.

> But any external module relying on GiST will have to provide for the new
> function you're thinking about, right? Updating was already needed to
> cope with the newer consistent API, I guess.

ISTM that it should be possible to allow an opclass to not supply the
new hook function if it doesn't support any ordering operators.  So
that's not really a serious problem.  The existing patch approaches
this by having two different APIs for the Consistent function depending
on whether the opclass supports ordering operators or not.  I find that
pretty icky, even though it nominally avoids breaking existing opclass
modules.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2010-12-01 15:36:51
Subject: Re: crash-safe visibility map, take three
Previous:From: Kevin GrittnerDate: 2010-12-01 15:26:24
Subject: Re: profiling connection overhead

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group