> > > > 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.
> > Got a start on it :)
> > regression=> explain select * from tenk1 where oid = 3000;
> > Index Scan using tenk1_oid on tenk1 (cost=2.05 size=1 width=148)
> > So, just curious: if we stop here, and only match up
> > binary-compatible built-in types with available indices, then what
> > v6.3.2 features/good behaviors are still missing?
> Did you put it in the optimizer?
It is inside backend/optimizer/path/indxpath.c. I'm using a bit of the
parser support code to help out. It has to be where the backend actually
is checking to see if an index is usable, which is in the optimization
step. Any earlier and we would have to look-ahead at the indices which
seems inappropriate.
> I think binary compatable types converted is going to be the easiest
> thing to do for index use. Not sure how you could try and break it.
> How about character string comparisons using indexes?
Will try some more tests, but it seems like it will be hard to break
since it only comes into effect with built-in datatypes which are
supposed to be binary compatible.
It would be interesting to try to do constant expressions and function
calls on constants next, though I'm thinking that it isn't required for
v6.4.
Vadim, will the executor know how to use a PARAM_EXEC node in any
context, or will we have to do some coding to get it recognized outside
of subselects? I'll need to figure out how to build one too, I
suppose...
- Tom
