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

Re: KNNGIST next step: adjusting indexAM API

From: Robert Haas <robertmhaas(at)gmail(dot)com>
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-11-30 21:09:40
Message-ID: AANLkTimYV9aZ1=c7xdhtWbpvWLOmvhKcm4+naX1q6rq9@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, Nov 30, 2010 at 2:50 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> In the current KNNGIST patch, the indexable ORDER BY clauses are
> transmitted to the executor by cramming them in with the index qual
> conditions (the IndexScan plan node's indexqual list), from whence
> they become part of the ScanKey array passed to the index AM.
> Robert complained that this was an ingenious way to minimize the
> number of lines touched by the patch but utterly ugly from any other
> standpoint, and I quite agree.  An ORDER BY clause is a completely
> different thing from a WHERE qual, so mixing them together doesn't
> seem like a good idea.
>
> However, if we hold to that principle then we need to modify the indexAM
> API to pass the ordering operators separately.  This is no big deal as
> far as the built-in AMs are concerned, particularly because 3 of the 4
> need only assert that the additional list is empty.  The only reason it
> would be a problem is if there were third-party index AMs that would be
> affected to a larger degree; but I don't know of any.  Does anyone have
> an objection to that?

None here.

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

In response to

pgsql-hackers by date

Next:From: Dimitri FontaineDate: 2010-11-30 21:10:55
Subject: Re: DELETE with LIMIT (or my first hack)
Previous:From: Tom LaneDate: 2010-11-30 21:08:25
Subject: Re: DELETE with LIMIT (or my first hack)

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