Re: Inconsistency between try_mergejoin_path and create_mergejoin_plan

Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> On Mon, Jun 17, 2024 at 10:51 PM Alexander Pyhalov
> <a(dot)pyhalov(at)postgrespro(dot)ru> wrote:
>> ERROR: could not find commutator for operator XXX

> It seems to me that the new operator is somewhat artificial, since it is
> designed to support a mergejoin but lacks a valid commutator. So before
> we proceed to discuss the fix, I'd like to know whether this is a valid
> issue that needs fixing.

Well, there's no doubt that the case is artificial: nobody who knew
what they were doing would install an incomplete opclass like this
in a production setting. However, there are several parts of the
planner that take pains to avoid this type of failure. I am pretty
sure that we are careful about flipping around candidate indexscan
quals for instance. And the "broken equivalence class" mechanism
is all about that, which is what equivclass.sql is setting up this
opclass to test. So I find it a bit sad if mergejoin creation is
tripping over this case.

I do not think we should add a great deal of complexity or extra
planner cycles to deal with this; but if it can be fixed at low
cost, we should.

regards, tom lane