ESQL: Refactor Join inside the planner #115813

costin · 2024-10-29T03:42:23Z

Previously the Join was modeled as a unary node, embedding the right side as a local relationship inside the node but not exposed as a child. This caused a lot the associated methods (like references, output and inputSet) to misbehave and the physical plan rules to pick incorrect information, such as trying to extract the local relationship fields from the underlying source - the fix was to the local relationship fields as ReferenceAttribute (which of course had its own set of issues). Essentially Join was acting both as a source and as a streaming operator.

This PR looks to address this partially by:

refactoring Join into a proper binary node with left and right branches which are used for its references and input/outputSet.
refactoring InlineStats to prefer composition and move the Aggregate on the join right branch. This reuses the Aggregate resolution out of the box; in the process remove the Stats interface.
update some of the planner rules that only worked with Unary nodes.
refactor Mapper into (coordinator) Mapper and LocalMapper.
remove Phased interface by moving its functionality inside the planner (no need to unpack the phased classes, the join already indicates the two branches needed).
massage the Phased execution inside EsqlSession
improve FieldExtractor to handle binary nodes
fix incorrect references in Lookup
generalize ProjectAwayColumns rule

Relates #112266

Not all inline and lookup tests are passing:

2 lookup fields are failing due to name clashes (qualifiers should fix this)
7 or so inline failures with a similar issue

I've disabled the tests for now to have them around once we complete
adding the functionality.

Previously the Join was modeled as a unary node, embedding the right side as a local relationship inside the node but not exposed as a child. This caused a lot the associated methods (like references, output and inputSet) to misbehave and the physical plan rules to pick incorrect information, such as trying to extract the local relationship fields from the underlying source - the fix was to the local relationship fields as ReferenceAttribute (which of course had its own set of issues). Essentially Join was acting both as a source and as a streaming operator. This PR looks to address this partially by: - refactoring Join into a proper binary node with left and right branches which are used for its references and input/outputSet. - refactoring InlineStats to prefer composition and move the Aggregate on the join right branch. This reuses the Aggregate resolution out of the box; in the process remove the Stats interface. - update some of the planner rules that only worked with Unary nodes. - refactor Mapper into (coordinator) Mapper and LocalMapper. - remove Phased interface by moving its functionality inside the planner (no need to unpack the phased classes, the join already indicates the two branches needed). - massage the Phased execution inside EsqlSession - improve FieldExtractor to handle binary nodes - fix incorrect references in Lookup - generalize ProjectAwayColumns rule Relates elastic#112266 Not all inline and lookup tests are passing: - 2 lookup fields are failing due to name clashes (qualifiers should fix this) - 7 or so inline failures with a similar issue I've disabled the tests for now to have them around once we complete adding the functionality.

elasticsearchmachine · 2024-10-29T03:42:47Z

Pinging @elastic/es-analytical-engine (Team:Analytics)

costin · 2024-10-29T03:43:24Z

...ck/plugin/esql/qa/testFixtures/src/main/java/org/elasticsearch/xpack/esql/EsqlTestUtils.java

@@ -599,7 +600,10 @@ else if (Files.isDirectory(path)) {
                Files.walkFileTree(path, EnumSet.allOf(FileVisitOption.class), 1, new SimpleFileVisitor<>() {
                    @Override
                    public FileVisitResult visitFile(Path file, BasicFileAttributes attrs) throws IOException {
-                        if (Regex.simpleMatch(filePattern, file.toString())) {


Fix to make CsvTests work inside the IDE against individual files ("lookup.csv-spec" vs "*.csv-spec)

costin · 2024-10-29T03:44:20Z

x-pack/plugin/esql/qa/testFixtures/src/main/resources/inlinestats.csv-spec

The commented tests are failing - the plan is to revisit them once lookup join is properly added. Right now this is not a priority...

Maybe add a comment so that these tests can easily be found later. As they are now, it's just an ignored set of tests.

costin · 2024-10-29T03:49:07Z

x-pack/plugin/esql/qa/testFixtures/src/main/resources/lookup.csv-spec

Only two tests are failing and the issue is name collision/merging in join.
Because there's no qualifier, given a field x we cannot determine at runtime from what side to extract the field - e.g.

FROM l | LOOKUP r ON k | KEEP a

during physical planning we know k is available on both l and r but have no idea whether a comes from l or r and thus cannot determine on what branch to place the field extractors.
There are different solutions to this approach but are outside of this PR - the most comprehensive one imo is name qualifiers but it's also the most complicated.

costin · 2024-10-29T03:49:49Z

x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/analysis/Analyzer.java

@@ -405,8 +405,8 @@ protected LogicalPlan doRule(LogicalPlan plan) {
                childrenOutput.addAll(output);
            }

-            if (plan instanceof Stats stats) {


By exposing the Aggregate, there's no reason to have the Stats interface anymore.
The upside is the Aggregate resolution gets reused automatically (including nested filters, etc..)

costin · 2024-10-29T03:50:14Z

x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/execution/PlanExecutor.java

@@ -47,7 +44,7 @@ public PlanExecutor(IndexResolver indexResolver, MeterRegistry meterRegistry) {
        this.indexResolver = indexResolver;
        this.preAnalyzer = new PreAnalyzer();
        this.functionRegistry = new EsqlFunctionRegistry();
-        this.mapper = new Mapper(functionRegistry);


functionRegistry is not used inside the Mapper.

costin · 2024-10-29T03:50:58Z

x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/execution/PlanExecutor.java

@@ -60,7 +57,7 @@ public void esql(
        EnrichPolicyResolver enrichPolicyResolver,
        EsqlExecutionInfo executionInfo,
        IndicesExpressionGrouper indicesExpressionGrouper,
-        BiConsumer<PhysicalPlan, ActionListener<Result>> runPhase,


Introduced a interface inside the generic BiConsumer to preserve the generics signature.

costin · 2024-10-29T03:51:13Z

...k/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/optimizer/LogicalPlanOptimizer.java

Just renames

costin · 2024-10-29T03:53:08Z

.../src/main/java/org/elasticsearch/xpack/esql/optimizer/rules/physical/ProjectAwayColumns.java

@@ -45,7 +44,7 @@ public PhysicalPlan apply(PhysicalPlan plan) {
        Holder<AttributeSet> requiredAttributes = new Holder<>(plan.outputSet());

        // This will require updating should we choose to have non-unary execution plans in the future.
-        return plan.transformDown(UnaryExec.class, currentPlanNode -> {


Make the rule work across all type of nodes - this took a while to figure out.

costin · 2024-10-29T03:53:38Z

.../java/org/elasticsearch/xpack/esql/optimizer/rules/physical/local/InsertFieldExtraction.java

@@ -40,7 +42,12 @@ public class InsertFieldExtraction extends Rule<PhysicalPlan, PhysicalPlan> {
    public PhysicalPlan apply(PhysicalPlan plan) {
        // apply the plan locally, adding a field extractor right before data is loaded
        // by going bottom-up
-        plan = plan.transformUp(UnaryExec.class, p -> {


Update the rule to work across all node types.

costin · 2024-10-29T03:55:40Z

x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/parser/LogicalPlanBuilder.java

@@ -84,7 +84,7 @@
 */
 public class LogicalPlanBuilder extends ExpressionBuilder {

-    private int queryDepth = 0;
+    interface PlanFactory extends Function<LogicalPlan, LogicalPlan> {}


Moved this interface at the beginning since otherwise in case of merging failure, when the file gets messed up, IntelliJ gets very confused and marks the whole file full of errors. By declaring it up front, it properly picks it up and significantly reduces the errors making it easy to determine where the missing bracket is.

costin · 2024-10-29T03:56:01Z

x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/plan/logical/BinaryPlan.java

A few convenient methods.

costin · 2024-10-29T03:57:15Z

x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/plan/logical/InlineStats.java

 * </p>
 */
-public class InlineStats extends UnaryPlan implements NamedWriteable, Phased, Stats {


Phased is no longer needed since there are no longer embedded nodes - these are now exposed in the plan, as first-class expressions; it's up to the planner, mapper and session to properly address them.

costin · 2024-10-29T03:58:33Z

x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/plan/logical/InlineStats.java

-            AttributeSet set = child().outputSet();
+            this.lazyOutput = mergeOutputAttributes(aggregate.output(), aggregate.child().output());
+        }
+        return lazyOutput;
+    }
+
+    // TODO: in case of inlinestats, the join key is always the grouping
+    private JoinConfig joinConfig() {
+        List<Expression> groupings = aggregate.groupings();
+        List<Attribute> namedGroupings = new ArrayList<>(groupings.size());
+        for (Expression g : groupings) {
+            namedGroupings.add(Expressions.attribute(g));
+        }



This part needs to be revisited and JoinConfig refactored to better incorporate the field resolution.

costin · 2024-10-29T03:59:24Z

x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/plan/logical/join/Join.java

-    protected AttributeSet computeReferences() {
-        return Expressions.references(config.leftFields()).combine(Expressions.references(config.rightFields()));
-    }


This is already happening in the parent.

costin · 2024-10-29T04:00:14Z

x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/plan/logical/join/Join.java

@@ -126,7 +117,7 @@ public static List<Attribute> computeOutput(List<Attribute> leftOutput, List<Att
            case LEFT -> {
                // Right side becomes nullable.
                List<Attribute> fieldsAddedFromRight = removeCollisionsWithMatchFields(rightOutput, matchFieldSet, matchFieldNames);
-                yield mergeOutputAttributes(makeNullable(makeReference(fieldsAddedFromRight)), leftOutput);


I believe this nifty workaround was used to prevent extraction from the source - now it's no longer needed (and furthermore creates problems in the planner).

costin · 2024-10-29T04:00:57Z

x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/plan/physical/HashJoinExec.java

-        LocalSourceExec hashData,
+        PhysicalPlan left,
+        PhysicalPlan hashData,


Make the 'embedded' subplan, part of the overall plan.

costin · 2024-10-29T04:01:30Z

x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/plan/physical/SubqueryExec.java

+/**
+ * Physical plan representing a subquery, meaning a section of the plan that needs to be executed independently.
+ */
+public class SubqueryExec extends UnaryExec {


Need to check but I believe we might not need this yet.

costin · 2024-10-29T04:02:43Z

x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/session/EsqlSession.java

+    private void executeSubPlans(
+        PhysicalPlan physicalPlan,
+        PlanRunner runner,
+        EsqlExecutionInfo executionInfo,
+        EsqlQueryRequest request,
+        ActionListener<Result> listener
+    ) {
+        List<PlanTuple> subplans = new ArrayList<>();
+
+        // Currently the inlinestats are limited and supported as streaming operators, thus present inside the fragment as logical plans
+        // Below they get collected, translated into a separate, coordinator based plan and the results 'broadcasted' as a local relation
+        physicalPlan.forEachUp(FragmentExec.class, f -> {
+            f.fragment().forEachUp(InlineJoin.class, ij -> {
+                // extract the right side of the plan and replace its source
+                LogicalPlan subplan = InlineJoin.replaceStub(ij.left(), ij.right());
+                // mark the new root node as optimized
+                subplan.setOptimized();
+                PhysicalPlan subqueryPlan = logicalPlanToPhysicalPlan(subplan, request);
+                subplans.add(new PlanTuple(subqueryPlan, ij.right()));
+            });
+        });
+
+        Iterator<PlanTuple> iterator = subplans.iterator();


multi "phase" execution - currently highly tailored to InlineJoin.

costin · 2024-10-29T04:03:23Z

x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/session/SessionUtils.java

Utils methods from Phased.

costin · 2024-10-29T04:04:03Z

x-pack/plugin/esql/src/test/java/org/elasticsearch/xpack/esql/plan/logical/PhasedTests.java

This needs to be resurrected as logical plan tests.

costin · 2024-10-30T05:40:35Z

x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/session/CcsUtils.java

@quux00 example of moving the CCS stuff outside EsqlSession. Essentially all static methods and the listener can easily be moved.

OK, it's mostly similar to what I did in my refactoring PR: https://github.com/elastic/elasticsearch/pull/115976/files#diff-4365e19b82cdd92b19ceba22a3178836bf06c2241f9ff4d1e9100fdef3b93dfd

So we can go with yours.

costin · 2024-10-30T05:41:25Z

x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/session/CcsUtils.java

+     * Any Exception sent to onFailure stops processing, but not all are fatal (return a 4xx or 5xx), so
+     * the onFailure handler determines whether to return an empty successful result or a 4xx/5xx error.
+     */
+    abstract static class CssPartialErrorsActionListener implements ActionListener<LogicalPlan> {


@quux00 Moved the listener out, keeping only the necessary bits and letting the caller implement the onResult()

I had a slightly different approach in my refactoring PR: https://github.com/elastic/elasticsearch/pull/115976/files#diff-40060e2ec9003953a228c4a03bdc80a301949b0d4e3dccc1978798e33a992a73R146

but this works, so if you prefer your model, that's fine with me.

costin · 2024-10-30T05:42:33Z

x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/session/EsqlSession.java

-            runPhase.accept(logicalPlanToPhysicalPlan(optimizedPlan, request), listener);
+        PhysicalPlan physicalPlan = logicalPlanToPhysicalPlan(optimizedPlan, request);
+        // TODO: this could be snuck into the underlying listener
+        CcsUtils.updateExecutionInfoAtEndOfPlanning(executionInfo);


@quux00 let me know if this makes sense.

The thing to test is to make sure it doesn't throw assertion errors when running with INLINESTATS, since that can do planning twice and this only wants to be called once (until we make it work with the 2 phase execution model). If it passes that, then it's fine for now. Based on reading the code below I think we're OK since the recursion is in executeSubPlans.

costin · 2024-10-30T05:43:17Z

x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/session/EsqlSession.java

+        Block[] blocks = SessionUtils.fromPages(schema, pages);
+        return new LocalRelation(plan.source(), schema, LocalSupplier.of(blocks));
+    }
+
    private LogicalPlan parse(String query, QueryParams params) {


@quux00 please double check this section.

Yes, looks good. Same thing I did in my refactoring PR. As long as the various CrossCluster IT tests (like CrossClustersQueryIT) pass, you're good.

astefan

LGTM

astefan · 2024-10-29T14:22:07Z

x-pack/plugin/esql/qa/testFixtures/src/main/resources/inlinestats.csv-spec

Maybe add a comment so that these tests can easily be found later. As they are now, it's just an ignored set of tests.

astefan · 2024-10-29T14:45:36Z

...k/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/plan/logical/join/StubRelation.java

+
+    @Override
+    public String commandName() {
+        return "<telemetry needs decoupling from the logical plan>";


My suggestion would be to create an issue and add a TODO here. I think this thing here will actually report a metric with this text string. CC @luigidellaquila

See the update to the TelemetryIT where a ghost STATS command is counted, separately from INLINESTATS
02fab88 (#115813)

astefan · 2024-10-30T15:05:26Z

...lugin/esql/src/main/java/org/elasticsearch/xpack/esql/plan/logical/SurrogateLogicalPlan.java

+package org.elasticsearch.xpack.esql.plan.logical;
+
+/**
+ * Interface signaling to the planner that the declaring plan.


I think the javadoc is incomplete :-).

astefan · 2024-10-30T15:16:30Z

x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/planner/mapper/Common.java

+/**
+ * Class for sharing code across Mappers.
+ */
+class Common {


The name doesn't say much and I think it could help a better one. Maybe MapperUtils?

astefan · 2024-10-30T16:46:51Z

.../java/org/elasticsearch/xpack/esql/optimizer/rules/physical/local/InsertFieldExtraction.java

-                // collect source attributes and add the extractor
-                var extractor = new FieldExtractExec(p.source(), p.child(), List.copyOf(missing));
-                p = p.replaceChild(extractor);
+                // identify child (for binary nodes) that exports doc values and place the field extractor there


I find it confusing to name this "doc values". Isn't this about doc id? (EsQueryExec.DOC_ID_FIELD)

quux00

LGTM (I only reviewed the parts flagged around the CCS refactorings.) There are a few other minor things I did my refactoring PR, but we can probably close that PR in favor of yours and I'll make the other minor tweaks in my next non-refactoring PR.

quux00 · 2024-10-31T00:18:54Z

x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/session/CcsUtils.java

OK, it's mostly similar to what I did in my refactoring PR: https://github.com/elastic/elasticsearch/pull/115976/files#diff-4365e19b82cdd92b19ceba22a3178836bf06c2241f9ff4d1e9100fdef3b93dfd

So we can go with yours.

quux00 · 2024-10-31T00:20:07Z

x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/session/CcsUtils.java

+     * Any Exception sent to onFailure stops processing, but not all are fatal (return a 4xx or 5xx), so
+     * the onFailure handler determines whether to return an empty successful result or a 4xx/5xx error.
+     */
+    abstract static class CssPartialErrorsActionListener implements ActionListener<LogicalPlan> {


I had a slightly different approach in my refactoring PR: https://github.com/elastic/elasticsearch/pull/115976/files#diff-40060e2ec9003953a228c4a03bdc80a301949b0d4e3dccc1978798e33a992a73R146

but this works, so if you prefer your model, that's fine with me.

quux00 · 2024-10-31T00:22:52Z

x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/session/EsqlSession.java

-            runPhase.accept(logicalPlanToPhysicalPlan(optimizedPlan, request), listener);
+        PhysicalPlan physicalPlan = logicalPlanToPhysicalPlan(optimizedPlan, request);
+        // TODO: this could be snuck into the underlying listener
+        CcsUtils.updateExecutionInfoAtEndOfPlanning(executionInfo);


The thing to test is to make sure it doesn't throw assertion errors when running with INLINESTATS, since that can do planning twice and this only wants to be called once (until we make it work with the 2 phase execution model). If it passes that, then it's fine for now. Based on reading the code below I think we're OK since the recursion is in executeSubPlans.

quux00 · 2024-10-31T00:24:18Z

x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/session/EsqlSession.java

+        Block[] blocks = SessionUtils.fromPages(schema, pages);
+        return new LocalRelation(plan.source(), schema, LocalSupplier.of(blocks));
+    }
+
    private LogicalPlan parse(String query, QueryParams params) {


Yes, looks good. Same thing I did in my refactoring PR. As long as the various CrossCluster IT tests (like CrossClustersQueryIT) pass, you're good.

quux00 · 2024-10-31T00:30:35Z

x-pack/plugin/esql/src/test/java/org/elasticsearch/xpack/esql/session/EsqlSessionTests.java

@@ -45,7 +45,7 @@ public void testCreateIndexExpressionFromAvailableClusters() {
            executionInfo.swapCluster(remote1Alias, (k, v) -> new EsqlExecutionInfo.Cluster(remote1Alias, "*", true));
            executionInfo.swapCluster(remote2Alias, (k, v) -> new EsqlExecutionInfo.Cluster(remote2Alias, "mylogs1,mylogs2,logs*", true));

-            String indexExpr = EsqlSession.createIndexExpressionFromAvailableClusters(executionInfo);
+            String indexExpr = CcsUtils.createIndexExpressionFromAvailableClusters(executionInfo);


In a follow on PR, I'll remove this test and create a CCSUtils test to house these tests.

Thanks @quux00 - hope I didn't waste too much of your time with the duplicate PR. I ended up doing them while working on the merging conflicts and made the pings hoping to draw your attention before too long.

I'll try to get this is in ASAP so you can continue to add your own modification in.

costin · 2024-10-31T19:18:17Z

Backport to 8.x through #116045

* ESQL: Refactor Join inside the planner (#115813) First PR that introduces a Join as a first class citizen in the planner. Previously the Join was modeled as a unary node, embedding the right side as a local relationship inside the node but not exposed as a child. This caused a lot the associated methods (like references, output and inputSet) to misbehave and the physical plan rules to pick incorrect information, such as trying to extract the local relationship fields from the underlying source - the fix was to the local relationship fields as ReferenceAttribute (which of course had its own set of issues). Essentially Join was acting both as a source and as a streaming operator. This PR looks to partially address this by: - refactoring Join into a proper binary node with left and right branches which are used for its references and input/outputSet. - refactoring InlineStats to prefer composition and move the Aggregate on the join right branch. This reuses the Aggregate resolution out of the box; in the process remove the Stats interface. - update some of the planner rules that only worked with Unary nodes. - refactor Mapper into (coordinator) Mapper and LocalMapper. - remove Phased interface by moving its functionality inside the planner (no need to unpack the phased classes, the join already indicates the two branches needed). - massage the Phased execution inside EsqlSession - improve FieldExtractor to handle binary nodes - fix incorrect references in Lookup - generalize ProjectAwayColumns rule Relates #112266 Not all inline and lookup tests are passing: - 2 lookup fields are failing due to name clashes (qualifiers should fix this) - 7 or so inline failures with a similar issue I've disabled the tests for now to have them around once we complete adding the functionality. (cherry picked from commit 4ee98e8) * ES|QL: Mute test for #116003 (#116005) (cherry picked from commit 681f509) --------- Co-authored-by: Luigi Dell'Aquila <[email protected]>

costin added the :Analytics/ES|QL AKA ESQL label Oct 29, 2024

costin requested review from nik9000, astefan, bpintea, alex-spies and fang-xing-esql October 29, 2024 03:42

elasticsearchmachine added Team:Analytics Meta label for analytical engine team (ESQL/Aggs/Geo) v9.0.0 labels Oct 29, 2024

costin commented Oct 29, 2024

View reviewed changes

...k/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/optimizer/LogicalPlanOptimizer.java Outdated

Copy link

Member Author

costin Oct 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just renames

costin commented Oct 29, 2024

View reviewed changes

x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/plan/logical/BinaryPlan.java Outdated

Copy link

Member Author

costin Oct 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few convenient methods.

costin commented Oct 29, 2024

View reviewed changes

x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/session/SessionUtils.java Outdated

Copy link

Member Author

costin Oct 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Utils methods from Phased.

costin commented Oct 29, 2024

View reviewed changes

costin commented Oct 30, 2024

View reviewed changes

costin added 3 commits October 30, 2024 00:20

Fix typo

fe0cdeb

disable more tests

894e0f3

Merge branch 'main' into esql/inlinestats-as-join

86f6cd9

astefan approved these changes Oct 30, 2024

View reviewed changes

astefan reviewed Oct 30, 2024

View reviewed changes

costin added 2 commits October 30, 2024 16:01

Address feedback

1486dff

Add dedicated Capability to help with mixed clusters

863b02d

costin force-pushed the esql/inlinestats-as-join branch from 4b44b4e to 863b02d Compare October 30, 2024 23:20

quux00 approved these changes Oct 31, 2024

View reviewed changes

quux00 reviewed Oct 31, 2024

View reviewed changes

quux00 mentioned this pull request Oct 31, 2024

Refactor CCS handling code from EsqlSession and IndexResolver into dedicated util class #115976

Closed

Update more tests

b0d261a

costin force-pushed the esql/inlinestats-as-join branch 2 times, most recently from 06da516 to 02fab88 Compare October 31, 2024 02:12

Update telemetry IT

8ffc167

costin force-pushed the esql/inlinestats-as-join branch from 02fab88 to 8ffc167 Compare October 31, 2024 04:31

costin enabled auto-merge (squash) October 31, 2024 04:33

costin merged commit 4ee98e8 into elastic:main Oct 31, 2024
16 checks passed

costin deleted the esql/inlinestats-as-join branch October 31, 2024 05:35

luigidellaquila mentioned this pull request Oct 31, 2024

[CI] ES|QL TelemetryIT.testMetrics failure #116003

Open

costin added the backport pending label Oct 31, 2024

costin added backport and removed backport pending backport labels Oct 31, 2024

ESQL: Refactor Join inside the planner #115813

ESQL: Refactor Join inside the planner #115813

Conversation

costin commented Oct 29, 2024

elasticsearchmachine commented Oct 29, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

costin Oct 29, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

costin Oct 30, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

astefan left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

quux00 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

costin commented Oct 31, 2024

costin Oct 29, 2024 •

edited

Loading

costin Oct 30, 2024 •

edited

Loading