Re: knngist - 0.8 - Mailing list pgsql-hackers

From Teodor Sigaev
Subject Re: knngist - 0.8
Date
Msg-id 4CDD8657.6020903@sigaev.ru
Whole thread Raw
In response to Re: knngist - 0.8  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: knngist - 0.8
List pgsql-hackers
> Slightly-more-fleshed out proof of concept patch attached, with actual
> syntax, documentation, and pg_dump support added.  This might be
> thought of as a subset of the builtin_knngist_core patch, without the
> parts that make it actually do something useful (which is mostly
> match_pathkey_to_index - which I'm still rather hoping to abstract in
> some way via the access method interface, though I'm currently unsure
> what the best way to do that is).

I don't see in your patch how to propagate knowledge of kind of operation 
(AMOP_SEARCH or AMOP_ORDER) to GiST and consistent method. For both of them they 
aren't distinguishable. That's not acceptably for both, because GiST needs to 
choose right traversal algorithm, consistentFn needs role to decide return 
infinity or false (-1) value.

My variants informs GiST by SK_ORDER flags and consistentFn looks at strategy 
number (strategy numbers are different for different purposes).


> I notice that builtin_knngist_core checks whether the return type of
> an ordering operator has a built-in btree opclass.  I'm not sure
Actually, GiST doesn't use that knowledge, check is done only to be sure that 
operation returns orderable data type.

> whether we should bother checking that, because even if it's true I
> don't think there's anything preventing it from becoming false later.
> I think it's probably sufficient to just check this condition at plan
> time and silently skip trying to build knn-type index paths if it's
> not met.

It's already do it: you can not ORDER BY over non-orderable data type. That 
check just make diagnostic earlier.

-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
  WWW: http://www.sigaev.ru/
 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: GIN vs. Partial Indexes
Next
From: Marko Tiikkaja
Date:
Subject: Re: wCTE behaviour