> > match_clause_to_indexkey() seems to be a starting point for what I
> > want to do. Will let you know how it goes...
> Check out my other posts on how op_class/pg_amop.amopopr is used to
> look up if the current expression operator is a member of the
> class(btree), and index opclass(oid_ops). I could probably code
> something so you could put multiple entries in pg_amop. My issue is
> that there are not that many interchangable operators to make that
> useful.
> Now, if you are thinking of doing some type of constant conversion
> there, that may be a bigger win. The issue is at this point in the
> code, there is no guarentee the index will be used. It is just
> checking the index usability.
> I think I see where you are going with this. For queries not
> involving indexes(many joins don't), it may be better to leave things
> for the executor.
The first thing I want to try is to substitute the operator for types
which are known to be binary-compatible and do not have their own index
defined. The next step would be to substitute an operator _and_ insert
an explicit type conversion using a function call (which may not work
yet for other reasons). Don't know where Vadim's PARAM_EXEC node comes
in, but if it does it might be around here.
> ... if you can, do a fresh cvs update if you can, because the code is
> a little cleaner now in that area. Particularly, the op_class()
> parameters were badly named, causing me confusion.
OK. Does the current source tree compile now? Haven't had much time to
look at it the last few days, but will start poking at it this evening a
bit.
- Tom
