I presume we’re talking about scalar sub-queries (e.g. sub-query in SELECT) and sub-queries with IN and EXISTS, as opposed to sub-queries in the FROM clause. The former are represented using RexSubQuery because the queries appear in scalar expressions.
There are rules to expand RexSubQuery into relational operators. After those rules have been applied, then I’m sure that the Hep engine will be able to find them. I think that’s what Haisheng is referring to. But while those sub-queries are still wrapped in RexSubQuery, it’s possible that the Hep engine won’t find them. Because it will have to walk over every RexNode inside a Project, Filter or Join and if that RexNode is a RexSubQuery, traverse into it to apply the rules to the RelNodes inside. I don’t know whether that happens today. Someone should check. It’s a reasonable ask (but there might be unforeseen consequences if we enable it by default). Julian > On Jun 9, 2021, at 12:02 PM, Haisheng Yuan <hy...@apache.org> wrote: > > Did you include the subquery related rules in the HepPlanner? > > Haisheng > > On 2021/06/09 17:59:44, Krishnakant Agrawal <kk.agrawa...@gmail.com> wrote: >> Hi All, >> >> When running a HepOptimizer on top of a RelNode which has a subquery >> embedded in it, The Optimizer does not take the RelNode representing the >> subquery up for optimization. >> >> Is this by design, what's the correct way for the Subquery RelNode to be >> picked up for Optimization? >> >> If this is a bug, what is the conceptually correct way to go about fixing >> this? >> >> Thanks, >> KK >>
