Re: Inconsistency between try_mergejoin_path and create_mergejoin_plan - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Inconsistency between try_mergejoin_path and create_mergejoin_plan
Date
Msg-id 48732.1718772591@sss.pgh.pa.us
Whole thread Raw
In response to Re: Inconsistency between try_mergejoin_path and create_mergejoin_plan  (Richard Guo <guofenglinux@gmail.com>)
Responses Re: Inconsistency between try_mergejoin_path and create_mergejoin_plan
List pgsql-hackers
Richard Guo <guofenglinux@gmail.com> writes:
> On Mon, Jun 17, 2024 at 10:51 PM Alexander Pyhalov
> <a.pyhalov@postgrespro.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



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: DOCS: Generated table columns are skipped by logical replication
Next
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: 001_rep_changes.pl fails due to publisher stuck on shutdown