Re: knngist patch support

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Tom remarked in another email that he wasn't too happy with the
> opclass changes. They seem kind of grotty to me, too, but I don't
> immediately have a better idea. My fear is that there may be places
> in the code that rely on opclass operators only ever returning bool,
> and that changing that may break things. It also feels like allowing
> non-bool-returning opclass members only for this one specific case is
> kind of a hack: is this an instance of some more general problem that
> we ought to be solving in some more general way? Not sure.

Yes, that's exactly what I didn't like about it: the proposed changes
create confusion between opclass members that represent
index-optimizable WHERE conditions and those that represent
index-optimizable ORDER BY conditions. You can get away with that to
some extent as long as you assume that the latter type of operator
never yields boolean and so can never appear at the top level of
WHERE. But that assumption sucks. There are plenty of cases where
people ORDER BY boolean values, so who's to argue that we will never
want an operator returning boolean in the second category? And as
soon as you put it in, the planner is going to think that it's also
a potential index-qualification operator, which is something the AM
might or might not be prepared to support.

I think this is really unacceptable and there needs to be some cleaner
way of distinguishing the two types of operators. Possibly a couple of
boolean columns added to pg_amop (you'd need two because there are three
possible states, in case an operator really can serve both purposes in a
particular opclass). Or maybe we should do something else. But
ignoring the issue won't do.

Maybe a more general idea would be to invent "categories" of opclass
members, where the only existing category is "index search qualifier",
and these new knngist thingies are another, and maybe plus and minus for
window function ranges are a third. But I'm not sure what you do if one
operator can be in more than one category.

regards, tom lane