On Mon, Jul 15, 2024 at 2:08 PM Andrei Lepikhov <lepi...@gmail.com> wrote: > > On 7/15/24 12:31, jian he wrote: > > hi. > > Here is the latest patch (v6), > > I've made the following changes. > > > > * disallow original Query->resultRelation participate in SJE. > > for SELECT, nothing is changed. for UPDATE/DELETE/MERGE > > we can do: > > EXPLAIN (COSTS OFF) > > UPDATE sj sq SET b = sq.b + sz.a FROM (select s1.* from sj s1 join sj > > s2 on s1.a = s2.a) as sz > > WHERE sz.a = sq.a; > > > > here, only "(select s1.* from sj s1 join sj s2 on s1.a = s2.a)" can > > apply to SJE. > > > > but for now we cannot apply SJE to > > EXPLAIN (COSTS OFF) > > UPDATE sj sq SET b = sq.b + sz.a FROM sj as sz WHERE sz.a = sq.a; > > > > so the EPQ abnormality issue[1] won't happen. > > > > > > * add a new function: ChangeVarNodesExtended for > > address concerns in [2] > I see you still stay with the code line: > if (omark && imark && omark->markType != imark->markType) > > It is definitely an error. What if omark is NULL, but imark is not? Why > not to skip this pair of relids? Or, at least, insert an assertion to > check that you filtered it earlier. >
i think "omark is NULL, but imark is not" case won't reach to remove_self_joins_one_group. In that case, omark associated RangeTblEntry->rtekind will be RTE_SUBQUERY, and will be skipped earlier in remove_self_joins_recurse. Still, do you think the following code is the right way to go? if ((omark == NULL && imark != NULL) || (omark != NULL && imark == NULL) || (omark && imark && omark->markType != imark->markType)) continue;
