On Sun, Nov 21, 2010 at 5:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I haven't spent any time on this patch yet (hope to start looking at it
> next week). As for your specific question above, I don't have a big
> problem with reusing ScanKey this way, but I do agree that using
> RestrictInfo for this would be a crock. ISTM what we ought to have is
> just the ability to match PathKeys with expressions of the form
> "indexedcol op constant" to an index.
That doesn't seem very hard on its face. The trick is what to do with
that information once you've got it. As far as I can tell, you need
to drill some kind of hole that lets you pass "additional details
about the desired sort order" to the index AM. What I'd sort of like
to be able to do is throw the PathKeys at the index AM and say "you
want these?". Short of that, we're probably going to have to resign
ourselves to the core code basically knowing exactly what the
capabilities of KNNGIST are, making the index API pretty porous - not
that it already isn't. There's really nothing special about the
subset of the problem space KNNGIST happens to attack except that it
makes the GIS guys drool; the next problem someone wants to attack in
this area is as likely as not to look completely different.
> This example leaves me totally cold, not least because it assumes a
> specific storage implementation for nulls in an index. It is also,
> I think, misunderstanding what ScanDirection is for. That's only
> intended to allow executor plans to be run forward and then backed up
> in the same fashion that fetching backwards from a cursor would do;
> which is not a btree-specific concept, indeed not even index-specific.
Ah, OK.
> If there is sufficient interest in doing what you suggest, what we'd
> want to do is pass the PathKey representation to the index and let the
> index AM figure out what it has to do to produce that sort order. But
> that is way way down my priority list.
Yeah, this is basically what I'm wondering whether we can reasonably
do for KNNGIST; with hopes of later reuse. But it may be unworkable.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company