Referencing a row seems to make sense. Especially for the composite key case:
select * from deptno where exists ( select 1 from dept where dept. country = emp.country and dept.deptno = emp.deptno and emp.age > 70 ); Do you ever need to find the distinct values of the correl variable? The variable should include (country, deptno) but should not include other fields such as dname. On Nov 24, 2014, at 12:03 PM, Vladimir Sitnikov <[email protected]> wrote: >> ’d choose one correlating variable at a time then pass over the whole tree >> to remove it (i.e. decorrelate) > > Do you mean a reference to a row or a reference to a field in the row? > > I alter CorrelateRel so it always declares a single correlated > variable (see https://gist.github.com/vlsi/e08f53b3fd0b3db465c0). > One CorrelateRel has always two inputs, and the "left" input is > referenced with a correlated variable. > When the correlated variable is used, it is referenced as a part of > RexFieldAccess(corrVar, field). > This simplifies implementation and allows to de-duplicate expressions. > >> Also, can we have a planning space that includes correlated and decorrelated >> versions of the same expressions? Probably, but I haven’t thought about it. > > I think it will somehow happen automagically if a LogicalCorrelate is > de-correlated. > >> and throw them at the decorrelator, maybe in the SqlToRelConverterTest. See >> what breaks. > > I am throwing the query at EnumerableImplementor. > The logic is simple: if correlated queries do not work (e.g. some > implementation limitation), I do not care if de-correlator breaks or > not. > > Vladimir
