Обсуждение: pgsql/src/test/regress/expected (opr_sanity.out)

  Date: Friday, July 28, 2000 @ 01:07:49
Author: tgl

Update of /home/projects/pgsql/cvsroot/pgsql/src/test/regress/expected
     from hub.org:/home/projects/pgsql/tmp/cvs-serv72125/test/regress/expected

Modified Files:
    opr_sanity.out

-----------------------------  Log Message  -----------------------------

Add int2-vs-int8 comparison operators.  These are now necessary because
the planner may try to generate them as a result of transitivity of the
existing int2-vs-int4 and int4-vs-int8 operators.  In fact, it is now
necessary that mergejoinable cross-datatype operators form closed sets.
Add an opr_sanity regress test to detect missing operators.

> Add int2-vs-int8 comparison operators.  These are now necessary because
> the planner may try to generate them as a result of transitivity of the
> existing int2-vs-int4 and int4-vs-int8 operators.  In fact, it is now
> necessary that mergejoinable cross-datatype operators form closed sets.
> Add an opr_sanity regress test to detect missing operators.

I'm suprised that this required adding only one extra set of operators!
In general, would it be possible to allow the planner to reformulate the
plan using nested conversions *if* the required operator is not
available?

                     - Thomas

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
>> Add int2-vs-int8 comparison operators.  These are now necessary because
>> the planner may try to generate them as a result of transitivity of the
>> existing int2-vs-int4 and int4-vs-int8 operators.  In fact, it is now
>> necessary that mergejoinable cross-datatype operators form closed sets.
>> Add an opr_sanity regress test to detect missing operators.

> I'm suprised that this required adding only one extra set of operators!

If it had needed more than that, I might've looked for another answer...

> In general, would it be possible to allow the planner to reformulate the
> plan using nested conversions *if* the required operator is not
> available?

Possibly, if we had an intelligent type promotion scheme that would make
a reliable choice about what to convert to which.  Right now I doubt you
could rely on the system to promote int2-v-int8 to something reasonable,
let alone two random user-defined types.

Another problem is that the planner is currently not very smart about
building joins using expressions --- if the arguments of an otherwise
mergeable/hashable '=' are not Vars, it won't try anything except the
stupidest form of nestloop.  So doing it this way is necessary to get
any planning win, at least till the planner gets smarter.

            regards, tom lane