> > I just tried adding the extra line, and initdb failed. I wonder if we
> > remove the oideqint4, if the parser will go for oideq?
>
> If you want to try this as an experiment, so we can tell if this is a
> possible solution, then great. I still have hopes that we can substitute
> other parse trees and strategies within the index utilization routines,
> so how about not committing things until we've tried a few options.
>
> match_clause_to_indexkey() seems to be a starting point for what I want
> to do. Will let you know how it goes...
OK. 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.
Also, 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.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
