Re: [HACKERS] Re: type coersion (was OR clause status)

Thomas G. Lockhart wrote:
>
> > > > > 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.

OK, I've just committed to the source tree changes for looking for
binary-compatible indices when either the left- or right-hand side of
the restriction clause is a constant.

I've #ifndef'd them so we can disable it if necessary. But, all of the
regression tests pass, except for the select_view test, which has been
core dumping for weeks. Anyone else seeing that, or is it just me? :(

- Tom