Re: join removal

On Sun, Jul 19, 2009 at 10:56 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> I think we want something along the lines of relation_is_distinct_for
> with a list of columns and a list of comparison operators, where the
> first-cut implementation will be to look for matching indexes.
> This will be different from query_is_distinct_for, but it's dealing
> with the same sorts of considerations about whether the operator
> semantics are the right things.

I took at a first crack at coding up an implementation of
relation_is_distinct_for() tonight.  Pseudocode:

for each indexoptinfo
{   if (not unique or not predOK or contains expressions)       skip it;   for c = 0 .. ind->ncolumns   {       opid =
distinct_col_search(ind->indexkeys[c],colnos, opids);       if (!OidIsValid(opid) || !equality_ops_are_compatible(opid,
XXXXXXXX))          break;   }   if (found them all)       return true;
 
}
return false;

distinct_col_search() is going to return the relevant equality
operator from the argument list, which is ultimately going to come
from the RestrictInfo for the join clause.  So I need to see whether
that's compatible with the index, but equality_ops_are_compatible()
wants two equality operators, and what I have is one equality operator
and one operator class.

Maybe it's sufficient to just check whether op_in_opfamily(opid,
ind->opfamily[c]), and skip equality_ops_are_compatible()?

I am having a hard time wrapping my brain around what it means to have
multiple, incompatible notions of equality... any help appreciated!

...Robert