Now unnest allows bound, in and selector filters on the unnested column by somu-imply · Pull Request #13799 · apache/druid

somu-imply · 2023-02-14T00:26:43Z

Previously even in the native query, Druid did not support filtering on the unnested column. In this PR we have introduced the following:

Added an allowFilter to use value matchers and advance cursors accordingly
Removed the allowList as we can support the same with filters

Unit tests have been added to address the following filters on the unnested column for both actual dimension and virtual columns

Selector filters
Bound filters
In filters

Unit tests have also been added for cases where multiple filters on unnested dimension and other dimensions on the input table are used together.

TBD: Pushing the filter on the unnested column as a filter on the dimension to be unnested on the left data source
This PR has:

…gative test cases where filtering on values not present in the column

…unnested columns

somu-imply · 2023-02-22T19:15:46Z

The filter on the unnested dimension or dimensions(in case of an expression using multiple columns) also needs to be pushed down to the datasource to limit the number of rows the cursor goes over. This will be done in a followup PR

…aky at times

somu-imply · 2023-02-23T00:08:38Z

@317brian @techdocsmith the docs are behaving flaky with

> spellcheck
> mdspell --en-us --ignore-numbers --report '../docs/**/*.md' || (./script/notify-spellcheck-issues && false)

    ../docs/tutorials/tutorial-jupyter-index.md
       41 | Jupyter both try to use port `8888`, so start Jupyter on a different por 

>> 1 spelling error found in 227 files

The document has port instead of por so this should not be thrown. I tried running spellcheck locally and things pass

paul-rogers · 2023-02-23T00:51:06Z

+      } else {
+        return;
+      }
+    }


Suggestion:

while (true) { boolean match = valueMatcher.matches(); advanceAndUpdate(); if (match || baseCursor.isDone()) { return; } }

Thanks this should be

while (true) { advanceAndUpdate(); boolean match = valueMatcher.matches(); if (match || baseCursor.isDone()) { return; } }

The match changes after the update so the call should be below. I'll add it

paul-rogers · 2023-02-23T00:52:21Z

+    // If the first value the index is pointing to does not match the filter
+    // advance the index to the first value which will match
+    if (!valueMatcher.matches()) {
+      advance();


Redundant. advanceUninterruptibly() already does the needed checks.

paul-rogers · 2023-02-23T00:53:51Z

    this.needInitialization = true;
-    this.allowSet = allowSet;
-    this.allowedBitSet = new BitSet();
+    this.allowFilter = allowFilter;


Here we allow a null filter. In the code above, we provided an "accept all" filter in this case. Should we do so here to avoid if null checks?

I did not understand this comment, can you please elaborate. On another note I'll remove the bitset it is not needed anymore

Paul's comment is asking you to re-evaluate if you need to store the reference to the Filter. In the ColumnValue version of the cursor, you do not store the reference to the Filter and instead generate a ValueMatcher that matches everything. But this code is keeping the reference, it would appear so that it can do an instanceof check.

I think the answer to Paul's comment is that you still need to do the logic to add the BitSet back to this implementation and, once you do that, you won't keep the reference to the Filter object and things will clean up a bit.

Yes I am working on the logic to add the bitset back. This will be a 1-time operation where I iterate over 0 to baseDimensionSelector.getValueCardinality() and look over each element to check if they match the filter or not and add to bitset if they match

paul-rogers · 2023-02-23T00:55:56Z

+            if (allowFilter instanceof InDimFilter) {
+              return ((InDimFilter) allowFilter).getValues().size();
+            } else if (allowFilter instanceof AndFilter) {
+              return ((AndFilter) allowFilter).getFilters().size();


Is this right? For an in filter, we know that the value has to be one of those in the list. But, for and, I can have anything can't I? x > 0 AND x < 1000 would have a cardinality of 1000 for a long type.

Valid point, we can only estimate it correctly for In filters (no in the in filter) and selector filter (should always be 1). This can get complicated for a filter such as d3='a' AND d3='b' where the cardinality will be equal to the size of the filters. I think Calcite would change that to d3 IN (a,b) so we should only handle the 2 cases

We cannot eliminate the bitset here. You need to be producing the bitset by applying the value matcher to the dictionary of values.

paul-rogers · 2023-02-23T00:56:14Z

+          return;
+        }
+      }
+    }


See suggestion above.

paul-rogers · 2023-02-23T01:04:39Z

+      // if there is a filter as d2 > 1 and unnest-d2 < 10
+      // Calcite would push the filter on d2 into the data source
+      // and only the filter on unnest-d2 < 10 will appear here
+      forBaseFilter = filter.getRequiredColumns().contains(outputColumnName) ? null : filter;


Nit:

final Filter forBaseFilter = filter == null || filter.getRequiredColumns().contains(outputColumnName) ? null : filter;

This code seems to assume a single filter. In the example, unnest-d2 < 10. But, what if my condition is unnest-d2 < 10 AND unnest_d2 > 5. Will this code work? And if only the unnest-d2 appears here, do we need to check the output column name?

To help understand this, it would be good to give a bit more of the query. What, exactly, is d2 here?

I'll add more comment. d2 is the column to be unnested. What I mean is that all filters on columns that exist in the datasource are pushed on to the data source. Only the filters on the unnested column appears here

The filter passed in here is all of the filters that have been pushed to the segment, including filters on the unnest column and other columns

It seems like you could potentially decompose the filter to partially push down anything that is is not filtering on the output column name into the base cursor so that the query can still use indexes and such, since otherwise the implication here is that if any filter is on the unnest column then it means we aren't going to use any indexes since we aren't pushing filter down to the base cursor.

QueryableIndexCursorSequenceBuilder does something like this with FilterAnalysis.analyzeFilter to partition the Filter into 'pre' and 'post' filters, the former which have bitmap indexes and go into computing the underying Offset, and the latter do the value matcher thing we are doing here.

paul-rogers · 2023-02-23T01:08:01Z

                  dimensionToUnnest,
                  outputColumnName,
-                  allowSet
+                  filter


Above, we may have passed the filter into the "base". If we did, do we want to reapply the same filter here? Or, should the above code actually be:

final Filter forBaseFilter; final Filter localFilter; if (filter == null || filter.getRequiredColumns().contains(outputColumnName) ) { forBaseFilter = filter; localFilter = null; } else { forBaseFilter = filter; localFilter = null; }

Then pass localFilter where we're passing filter?

The filter that appears here will be on the unnested column only. For example if you are unnesting dim3 to ud3, any filter on ud3 will appear here. The filter on ud3 cannot be pushed into base but can only be sent to the unnest cursor as an allow filter. There is scope of optimization here to rewrite the same filter on dim3 and push it to the base

paul-rogers · 2023-02-23T01:10:57Z

        "vc",
-        QueryRunnerTestHelper.PLACEMENTISH_DIMENSION_UNNEST,
-        null
+        QueryRunnerTestHelper.PLACEMENTISH_DIMENSION_UNNEST


Sorry, what is a PLACEMENTISH?

It is a dimension in our test setup that is of the format placement,<some_string>

paul-rogers · 2023-02-23T01:13:53Z

    Assert.assertEquals(k, 10);
  }

-  @Test


Should these tests be retained, but updated to whatever the new format is? Presumably these addressed some earlier concern, and we should ensure that they still work. Or, are there new tests that cover the same cases that the deleted tests cover?

There are new tests that cover these. They are added in the CalciteArraysQueryTest

ideally there should be tests added here too... I would expect tests here to be checking stuff like the cursor spits out the expected filtered number of rows, etc.

I guess the storage adapter test partially covers this, but the more tests the better

paul-rogers · 2023-02-23T01:18:11Z

        "dummy",
        OUTPUT_NAME,
-        IGNORE_SET
+        null


Do these tests a wide range of predicates (filters) on the unnested value? I worry that the code above handles only simple cases: unnested_value op constant. Do they also handle complex cases such as fn(unnested_value) > some_other_col? fn(unnested_value) > 10 AND unnested_value * 3 > 12? Would be good to have tests that exercise these non-trivial cases.

somu-imply · 2023-02-27T23:57:48Z

The one failing test here will be resolved once #13860 gets merged

clintropolis · 2023-02-28T02:32:43Z

+    skipVectorize();
+    cannotVectorize();
+    testQuery(
+        "SELECT d3 FROM druid.numfoo, UNNEST(MV_TO_ARRAY(dim3)) as unnested (d3) where d3 IN ('d','c') ",


to clarify, is the d3 in these tests is referring to unnested.d3 or druid.numfoo.d3? it seems maybe a bit confusing to the casual reader to name the unnested thing the same thing as the underlying column name which was trasnformed with MV_TO_ARRAY (though maybe nice to intentionally cover this in at least one test with comment clarifying the confusing aliases is actually filtering on the unnested output column and not d3)

Also, should there be tests filtering on d3 where the native query plans to filtering on d3 directly instead of the unnested column, similar to the tests with filters directly on the numeric array elements in other tests? That said, that doesn't really go through the new codepaths here, so is more just a bonus coverage.

oh, i got confused from all the repetitive patterns in this query, d3 isn't dim3, another instance of me not being able to read 😭

clintropolis · 2023-02-28T02:44:03Z

    ScanQueryRunnerTest.verify(ascendingExpectedResults, results);
  }

-  @Test


this should probably be replaced with scan queries which filter on the unnested output column name

clintropolis · 2023-02-28T02:45:35Z

    Assert.assertEquals(k, 10);
  }

-  @Test


ideally there should be tests added here too... I would expect tests here to be checking stuff like the cursor spits out the expected filtered number of rows, etc.

I guess the storage adapter test partially covers this, but the more tests the better

clintropolis · 2023-02-28T03:36:54Z

+      // if there is a filter as d2 > 1 and unnest-d2 < 10
+      // Calcite would push the filter on d2 into the data source
+      // and only the filter on unnest-d2 < 10 will appear here
+      forBaseFilter = filter.getRequiredColumns().contains(outputColumnName) ? null : filter;


The filter passed in here is all of the filters that have been pushed to the segment, including filters on the unnest column and other columns

It seems like you could potentially decompose the filter to partially push down anything that is is not filtering on the output column name into the base cursor so that the query can still use indexes and such, since otherwise the implication here is that if any filter is on the unnest column then it means we aren't going to use any indexes since we aren't pushing filter down to the base cursor.

QueryableIndexCursorSequenceBuilder does something like this with FilterAnalysis.analyzeFilter to partition the Filter into 'pre' and 'post' filters, the former which have bitmap indexes and go into computing the underying Offset, and the latter do the value matcher thing we are doing here.

clintropolis · 2023-02-28T03:42:57Z


  @Test
-  public void test_unnest_adapters_with_allowList()
+  public void test_unnest_adapters_basic_with_in_filter()


imo please add more tests here, including tests with filters on other columns if possible, since the unnest cursor wraps a base cursor, just to make sure no funny stuff is happening.

If there is a test suite for "normal" cursor stuff, it would be great to be able to plug this into one of those. Those should all be able to pass without any errors as long as they aren't referencing the actual unnested column.

I haven't looked to see how easy it will be to reuse that test suite, but it's worth it to explore what can be done to be able to reuse it.

clintropolis · 2023-02-28T04:11:43Z

+    skipVectorize();
+    cannotVectorize();
+    testQuery(
+        "SELECT d3 FROM druid.numfoo, UNNEST(MV_TO_ARRAY(dim3)) as unnested (d3) where d3 IN ('foo','bar') ",


please add a test where there are filters on other columns too (a mix of filter on unnested column and filter on some other column)

There is 1 already SELECT d12 FROM druid.numfoo, UNNEST(ARRAY[m1, m2]) as unnested (d12) where d12 IN ('1','2') AND m1 < 10

clintropolis · 2023-02-28T04:17:17Z

+    } else if (partialQuery.getUnnestFilter() != null) {
+      filter = Preconditions.checkNotNull(
+          computeUnnestFilter(
+              partialQuery,
+              plannerContext,
+              sourceRowSignature,
+              virtualColumnRegistry
+          )
+      );


can you not have both a where filter an an unnest filter? is an unnest filter basically a where filter that got picked up somewhere else?

Yes an unnest filter is same as a where or having that gets picked up somewhere else

somu-imply · 2023-02-28T22:51:26Z

It seems like you could potentially decompose the filter to partially push down anything that is is not filtering on the output column name into the base cursor so that the query can still use indexes and such, since otherwise the implication here is that if any filter is on the unnest column then it means we aren't going to use any indexes since we aren't pushing filter down to the base cursor.

Calcite is smart enough to push the filter on an existing dimension to the underlying datasource. For example a query like

with t as (select * from druid.numfoo,UNNEST(MV_TO_ARRAY(dim3)) as foo(d3))
select d3 from t where d3 >1 AND dim2 IN ('a','b')

Calcite plans it as

157:LogicalProject(d3=[$17])
  155:LogicalCorrelate(subset=[rel#156:Subset#7.NONE.[]], correlation=[$cor0], joinType=[inner], requiredColumns=[{3}])
    144:LogicalFilter(subset=[rel#145:Subset#1.NONE.[]], condition=[OR(=($2, 'a'), =($2, 'b'))])
      9:LogicalTableScan(subset=[rel#143:Subset#0.NONE.[]], table=[[druid, numfoo]])
    151:LogicalFilter(subset=[rel#152:Subset#5.NONE.[]], condition=[>(CAST($0):INTEGER, 1)])
      149:Uncollect(subset=[rel#150:Subset#4.NONE.[]])
        147:LogicalProject(subset=[rel#148:Subset#3.NONE.[]], EXPR$0=[MV_TO_ARRAY($cor0.dim3)])
          10:LogicalValues(subset=[rel#146:Subset#2.NONE.[0]], tuples=[[{ 0 }]])

imply-cheddar

The way that this is planning is going to create very sub-optimal runs and limitations on query running that shouldn't exist.

The code strategy should've been to replace the allow list with a Filter object and then work with that. We cannot merge this code as is and must change it around to replacing the allow list with a Filter object and then applying that.

imply-cheddar · 2023-03-01T01:31:09Z

+            if (allowFilter instanceof InDimFilter) {
+              return ((InDimFilter) allowFilter).getValues().size();
+            } else if (allowFilter instanceof AndFilter) {
+              return ((AndFilter) allowFilter).getFilters().size();


We cannot eliminate the bitset here. You need to be producing the bitset by applying the value matcher to the dictionary of values.

imply-cheddar · 2023-03-01T01:38:11Z

      }
    } else {
-      if (index >= indexedIntsForCurrentRow.size() - 1) {
+      if (indexForRow >= indexedIntsForCurrentRow.size() - 1) {


IndexedInt is a class in the Druid code base. It's logically equivalent to an int[]. The values are references to the dictionary. There is some javadoc that attempts to explain these things on interfaces like DimensionSelector and DimensionDictionarySelector

imply-cheddar · 2023-03-01T01:43:26Z

      String columnName,
-      String outputName,
-      LinkedHashSet<String> allowList
+      String outputName
  )


I had expected you to change the allowList to a Filter but keep it on this object. It looks like you are assuming that the filter passed into the call to make the cursor is good enough. In the "best" case, you are planning things to attach the filter on the unnested thing to the other filters being included, in which case, as clint mentions, the entire filter is moving to a value matcher with absolutely nothing being pushed down. In the worst case, some of the filters are being lost in planning and incorrect results can occur. I haven't validated which one of these is likely occuring yet.

Given that Calcite very clearly puts the filter on the UNCOLLECT, you should be able to just attach a Filter object here instead of putting it on the query as a whole. The logic inside of this should remain more or less the same as what it was before with the allow list, just, you are applying a value predicate to the dictionaries instead of building a bitset.

The filter used to make the cursor should continue to be passed down (though it should also have the filter that is attached here adjusted and pushed down as well).

imply-cheddar · 2023-03-01T01:51:03Z

+  public void testUnnestWithFilteringOnUnnestedVirtualCol()
+  {
+    skipVectorize();
+    cannotVectorize();
+    testQuery(
+        "SELECT d12 FROM druid.numfoo, UNNEST(ARRAY[m1, m2]) as unnested (d12) where d12 IN ('1','2') AND m1 < 10",
+        ImmutableList.of(
+            Druids.newScanQueryBuilder()
+                  .dataSource(UnnestDataSource.create(
+                      new QueryDataSource(
+                          newScanQueryBuilder()
+                              .dataSource(
+                                  new TableDataSource(CalciteTests.DATASOURCE3)
+                              )
+                              .intervals(querySegmentSpec(Filtration.eternity()))
+                              .resultFormat(ScanQuery.ResultFormat.RESULT_FORMAT_COMPACTED_LIST)
+                              .legacy(false)
+                              .filters(bound("m1", null, "10", false, true, null, StringComparators.NUMERIC))
+                              .columns(
+                                  "__time",
+                                  "cnt",
+                                  "d1",
+                                  "d2",
+                                  "dim1",
+                                  "dim2",
+                                  "dim3",
+                                  "dim4",
+                                  "dim5",
+                                  "dim6",
+                                  "f1",
+                                  "f2",
+                                  "l1",
+                                  "l2",
+                                  "m1",
+                                  "m2",
+                                  "unique_dim1"
+                              )
+                              .context(QUERY_CONTEXT_DEFAULT)
+                              .build()
+                      ),
+                      "v0",
+                      "EXPR$0"
+                  ))
+                  .intervals(querySegmentSpec(Filtration.eternity()))
+                  .resultFormat(ScanQuery.ResultFormat.RESULT_FORMAT_COMPACTED_LIST)
+                  .legacy(false)
+                  .context(QUERY_CONTEXT_DEFAULT)
+                  .virtualColumns(expressionVirtualColumn("v0", "array(\"m1\",\"m2\")", ColumnType.FLOAT_ARRAY))
+                  .filters(new InDimFilter("EXPR$0", ImmutableList.of("1.0", "2.0"), null))
+                  .columns(ImmutableList.of(
+                      "EXPR$0"
+                  ))
+                  .build()
+        ),
+
+        ImmutableList.of(
+            new Object[]{1.0f},
+            new Object[]{1.0f},
+            new Object[]{2.0f},
+            new Object[]{2.0f}
+        )
+    );
+  }


So, from looking at how things are planned, I thought that we were throwing away the actual where clause. Instead, this test showed me what is actually happening: when we have both filters, the unnest is being planned on top of a scan query which carries the original filter.

This is a bad plan, it is going to needlessly force things to run on the Broker instead of being pushed down. The unnest should be pushed down onto the actual TableDataSource and the native query here should be a singular scan on top of an unnest data source of a table reference.

somu-imply · 2023-03-04T21:21:21Z

The following things have been addressed:

Filter moved inside unnest data source
A transformation is introduced that creates the partial query on the correlate from the partial query on the left
We only create a query data source if there is a LIMIT as the limit needs to be honored before unnest
Updated test cases.

Things to be done:

Add more tests
Modify getValueCardinality for the dimension cursor
Transform the filter on the unnested output column to filters on the left and pass them to the base cursor

somu-imply · 2023-03-04T21:35:50Z


-    UNNEST_PROJECT
+    UNNEST_PROJECT,
+    UNNEST_FILTER


This needs to be removed

…d instead

imply-cheddar

Leaving some comments here. As I did the review, I think that you are likely still in the process of adjusting things as some of the stuff that we've discussed directly isn't yet reflected here.

imply-cheddar · 2023-03-06T05:22:21Z

    this.needInitialization = true;
-    this.allowSet = allowSet;
+    if (filter != null) {
+      this.valueMatcher = filter.makeMatcher(getColumnSelectorFactory());


Given that this is called in the constructor and then also returned as a public method, maybe switch it around to have the constructor create the ColumnSelectorFactory, store the reference and then use that here/return it from the getColumnSelectorFactory method.

imply-cheddar · 2023-03-06T05:26:02Z

    this.needInitialization = true;
-    this.allowSet = allowSet;
-    this.allowedBitSet = new BitSet();
+    this.allowFilter = allowFilter;


Paul's comment is asking you to re-evaluate if you need to store the reference to the Filter. In the ColumnValue version of the cursor, you do not store the reference to the Filter and instead generate a ValueMatcher that matches everything. But this code is keeping the reference, it would appear so that it can do an instanceof check.

I think the answer to Paul's comment is that you still need to do the logic to add the BitSet back to this implementation and, once you do that, you won't keep the reference to the Filter object and things will clean up a bit.

imply-cheddar · 2023-03-06T05:29:32Z


  @Test
-  public void test_unnest_adapters_with_allowList()
+  public void test_unnest_adapters_basic_with_in_filter()


If there is a test suite for "normal" cursor stuff, it would be great to be able to plug this into one of those. Those should all be able to pass without any errors as long as they aren't referencing the actual unnested column.

I haven't looked to see how easy it will be to reuse that test suite, but it's worth it to explore what can be done to be able to reuse it.

imply-cheddar · 2023-03-06T05:32:38Z

+    // If there is a LIMIT in the left query
+    // It should be honored before unnest
+    // Create a query data source in that case


What kind of query is that? Do we have a test covering it? I'm not sure I believe this comment is true, but I also am not able to imagine a query that can do this.

Yes we have a test case, the query is like
SELECT d3 FROM (select * from druid.numfoo where dim2 IN ('a','b','ab','abc') LIMIT 2), UNNEST(MV_TO_ARRAY(dim3)) as unnested (d3)

Here the limit from the left cannot be applied outside

imply-cheddar · 2023-03-06T07:07:54Z

+  private PartialDruidQuery updateCorrPartialQueryFromLeft(PartialDruidQuery partialQueryFromLeft)
+  {
+    // The DruidCorrelateRule already creates the project and pushes it on the top level
+    // So get select project from partialQuery
+    // The filters are present on the partial query of the left
+    // The group by and having clauses would be on the top level
+    // Same for the sort
+    PartialDruidQuery corrQuery = PartialDruidQuery.create(correlateRel);
+    corrQuery = corrQuery.withWhereFilter(partialQueryFromLeft.getWhereFilter())
+                         .withSelectProject(partialQuery.getSelectProject());
+    if (partialQuery.getAggregate() != null) {
+      corrQuery = corrQuery.withAggregate(partialQuery.getAggregate())
+                           .withHavingFilter(partialQuery.getHavingFilter());
+    }
+    if (partialQuery.getSort() != null || partialQuery.getSortProject() != null) {
+      corrQuery = corrQuery.withSort(partialQuery.getSort());
+    }
+    return corrQuery;
+  }
+


This feels like we are throwing away the left-hand side and instead trying to build a query from the unnest part? Taht seems wrong to me, we should be using the unnest on the RHS to augment the query from the LHS (attach to the datasource). the LHS is the actual working query, the RHS is just the addition of the unnest portion.

The DruidCorrelateUnnestRule already put the select project on top of the correlateRel by adding all the things in right to the left. Also the group by, order by on the query are already present on the correlateRel. So we create the query by adding the select project (the one which is already projected on top with left + right), the filters from the left + aggregates (if present) + sorts if present on the top level

gianm · 2023-03-07T12:37:28Z

@somu-imply could you please have a look at #13892? That has some changes that I started doing as part of looking into upgrading Calcite. The upgrade borked a bunch of the existing UNNEST tests and exposed some issues with how the planning works, which led to invalid plans. The changes in the #13892 should fix up the planning. IMO the logic is also cleaner.

…tset

-    final DruidRel<?> newDruidRelFilter;
+    final DruidRel<?> newDruidRel;
    final List<RexNode> newProjectExprs = new ArrayList<>();
+    final List<RexNode> newWheres = new ArrayList<>();


+            @Override
+            public double getDouble()
+            {
+              return Double.parseDouble(dimSelector.lookupName(idRef.get()));


somu-imply · 2023-03-23T23:36:04Z

Closed in favor of #13934

Now unnest allows bound, in and selector filters on the unnested column

e8de6dc

github-advanced-security AI found potential problems Feb 14, 2023

View reviewed changes

Comment thread processing/src/test/java/org/apache/druid/segment/UnnestStorageAdapterTest.java Fixed

somu-imply added 2 commits February 15, 2023 11:06

Filters on unnested columns over virtual columns

9743911

Removing allowList to make way for filters

933ccbe

somu-imply marked this pull request as ready for review February 21, 2023 17:45

Support for filters on unnested column in SQL part 1

e77643a

somu-imply marked this pull request as draft February 21, 2023 18:26

somu-imply added 2 commits February 21, 2023 11:47

Adding a test on virtual column and bound filters

ce5e5a6

Removing an older test that is now supported through sql

a2ca449

somu-imply marked this pull request as ready for review February 22, 2023 02:47

somu-imply added 2 commits February 21, 2023 21:18

Fixing an issue with initialization in unnestDim cursor and adding ne…

ff4d6ea

…gative test cases where filtering on values not present in the column

Adding support and unit tests for all kinds of selector filters over …

663292a

…unnested columns

github-advanced-security AI found potential problems Feb 22, 2023

View reviewed changes

Comment thread sql/src/main/java/org/apache/druid/sql/calcite/rule/DruidFilterUnnestRule.java Fixed

Updating a md file for spellcheck to pass, although it is behaving fl…

f138c6d

…aky at times

github-actions Bot added the Area - Documentation label Feb 22, 2023

paul-rogers requested changes Feb 23, 2023

View reviewed changes

somu-imply added 2 commits February 22, 2023 20:56

Merge remote-tracking branch 'upstream/master' into filtersOnUnnest

bb643ac

Simplifying the advance logic for cursors

e969e6a

somu-imply force-pushed the filtersOnUnnest branch from a0bee37 to e969e6a Compare February 27, 2023 21:08

clintropolis reviewed Feb 28, 2023

View reviewed changes

imply-cheddar suggested changes Mar 1, 2023

View reviewed changes

somu-imply marked this pull request as draft March 2, 2023 16:54

github-advanced-security AI found potential problems Mar 3, 2023

View reviewed changes

Comment thread sql/src/main/java/org/apache/druid/sql/calcite/rel/PartialDruidQuery.java Fixed

Changes for moving filter inside the unnest data source

5031f9f

somu-imply force-pushed the filtersOnUnnest branch from 6b62adc to 5031f9f Compare March 4, 2023 21:14

Adding some comments and updating some javadocs

737771b

somu-imply commented Mar 4, 2023

View reviewed changes

Do not need planner context in the new rules, using an instance metho…

744fb7b

…d instead

imply-cheddar reviewed Mar 6, 2023

View reviewed changes

Tmp changes for filter matching

0bb44c5

somu-imply mentioned this pull request Mar 7, 2023

Various changes and fixes to UNNEST. #13892

Merged

somu-imply and others added 2 commits March 8, 2023 16:52

Updating dimension cursor to use value matcher once and populate a bi…

c9074b6

…tset

Merge branch 'master' into filtersOnUnnest

c617443

github-advanced-security AI found potential problems Mar 9, 2023

View reviewed changes

somu-imply closed this Mar 23, 2023

somu-imply deleted the filtersOnUnnest branch March 23, 2023 23:36

Conversation

somu-imply commented Feb 14, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

somu-imply commented Feb 22, 2023

Uh oh!

Uh oh!

somu-imply commented Feb 23, 2023

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

somu-imply Mar 6, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

somu-imply commented Feb 27, 2023

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

somu-imply commented Feb 14, 2023 •

edited

Loading

somu-imply Mar 6, 2023 •

edited

Loading

somu-imply commented Feb 28, 2023 •

edited

Loading