> 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/