> > > I claim the parser is doing the wrong thing by representing this as
> > > "where int4(i2) = 400::int4" rather than "where i2 = 400::int2".
> > > It is not really reasonable to expect the optimizer to clean up
> > > after that initial mistake.
> > I don't see that.
>
> Yup. The parser is behaving as Bruce describes. The new type conversion
> stuff isn't the fundamental problem. It's the original features in the
> planner when trying to use indices.
>
> > The problem is how do we use indexes for this? I am still researching
> > this.
>
> OK, let me know if I can help look into anything. In the meantime, I'll
> keep poking at it a bit...
I have also looked at x = oid(3) to see why functions are not being
used. That same function I mentioned match_clause_to_indexkey clearly
shows it does not support this:
/*
* If this is not a join clause, check for clauses of the form:
* (operator var/func constant) and (operator constant var/func)
*/
if (!join)
{
/*
* Check for standard s-argable clause
*/
if ((rightop && IsA(rightop, Const)) ||
(rightop && IsA(rightop, Param)))
{
restrict_op = ((Oper *) ((Expr *) clause)->oper)->opno;
isIndexable = (op_class(restrict_op, xclass, index->relam) &&
They want to use a functional index for oid(), but we are computing it
on a constant. Some code will have to be added somewhere to handle
this. If we want it done in the executor, perhaps we can look inside
the function to see if they are all consts, and handle it somehow.
Of course, if a function index does match, we should use that first.
--
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)
