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

Re: KNNGIST next step: adjusting indexAM API

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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 10:22:52
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

Now, of course, that's memories from Royal-Oak sessions, so it might be
all wrong too :)

Dimitri Fontaine     PostgreSQL : Expertise, Formation et Support

In response to


pgsql-hackers by date

Next:From: Dann CorbitDate: 2010-12-01 10:34:03
Subject: Re: Proposal: First step towards Intelligent,integrated database
Previous:From: ghatpandeDate: 2010-12-01 10:19:32
Subject: Proposal: First step towards Intelligent,integrated database

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