ESQL: INLINESTATS implementation with multiple LogicalPlan updates #128917

astefan · 2025-06-04T15:54:20Z

Part of #124715 and similar to #128476.
Different from #128476 in that it takes a "LogicalPlan" approach to running a sub-query, integrating its result back in the "main" LogicalPlan and continuing running the query.

coordinated from the EsqlSession.

elasticsearchmachine · 2025-06-04T15:55:11Z

Hi @astefan, I've created a changelog YAML for you.

the inlinestats JOIN

…support_multi_inlinestats_logicalPlan_approach

astefan · 2025-06-12T11:38:06Z

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

 | INLINESTATS min_scalerank=MIN(scalerank) BY type
 | MV_EXPAND type
-| WHERE scalerank == MV_MIN(scalerank);
+| EVAL mvMin_scalerank = MV_MIN(scalerank)


I didn't know the original intention with this test, so I've updated it to make some kind of sense and to also keep what I thought to be its original purpose.

astefan · 2025-06-12T11:40:31Z

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

-            // as first columns in the output followed by whatever the right hand side of join adds in this order: aggregates first,
-            // followed by groupings (this order should be preserved inside the rightFields() output)
-            output = mergeOutputAttributes(right, leftOutputWithoutMatchFields);
+            List<Attribute> leftOutputWithoutKeys = left.stream().filter(attr -> config().leftFields().contains(attr) == false).toList();


This is taken from @alex-spies great suggestion here

astefan · 2025-06-12T11:43:22Z

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

@@ -207,14 +206,10 @@ private PhysicalPlan mapBinary(BinaryPlan bp) {
                throw new EsqlIllegalArgumentException("unsupported join type [" + config.type() + "]");
            }

-            if (join instanceof InlineJoin) {


This temporary section has been removed; it was introduced with the first PR about reviving inlinestats, and it was also questioned about its usefulness. After changing the approach to use LogicalPlan rebuild (instead of PhysicalPlans) this part was not needed anymore.

…support_multi_inlinestats_logicalPlan_approach

elasticsearchmachine · 2025-06-12T12:45:38Z

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

bpintea

Nice work, LGTM.

My only significant note, not directly PR-specific, is having INLINESTATS hit the same source (i.e. with same filters, sorting, etc. that come before the first INLINESTATS) multiple times (i.e. for each INLINESTATS). It'd be great if we could save this computation and reuse it, that might become heavy otherwise if there's denser logic than just Lucene (like more LOOKUP JOINs, ENRICHes, and then more INLINESTATs). I guess we could look into this at some later point.

bpintea · 2025-06-26T12:41:11Z

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

            // execute main plan
            runner.run(physicalPlan, listener);
        }
    }

+    private LogicalPlanTuple firstSubPlan(LogicalPlan optimizedPlan) {


Actually maybe add a comment (or rename it) that it actually returns the completed / "destubbed" righthand side of the bottommost InlineJoin that's still stubbed -- the method is very specific to this command.

bpintea · 2025-06-26T14:03:11Z

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

        ActionListener<Result> listener
    ) {
-        PlanTuple tuple = subPlanIterator.next();
+        // Create a physical plan out of the logical sub-plan
+        var physicalSubPlan = logicalPlanToPhysicalPlan(subPlans.nonStubbedSubPlan, request);


Abs. optional, but these logs helped a bit go through the execution.

diff --git a/x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/session/EsqlSession.java b/x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/session/EsqlSession.java index d8118b0e0f4e..7fac395ddfb4 100644 --- a/x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/session/EsqlSession.java +++ b/x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/session/EsqlSession.java @@ -285,6 +285,7 @@ public class EsqlSession { EsqlQueryRequest request, ActionListener<Result> listener ) { + LOGGER.debug("Executing subplan:\n{}", subPlans.nonStubbedSubPlan); // Create a physical plan out of the logical sub-plan var physicalSubPlan = logicalPlanToPhysicalPlan(subPlans.nonStubbedSubPlan, request); @@ -300,10 +301,12 @@ public class EsqlSession { ij -> ij.right() == subPlans.originalSubPlan ? InlineJoin.inlineData(ij, resultWrapper) : ij ); newLogicalPlan.setOptimized(); + LOGGER.debug("Plan after previous subplan execution:\n{}", newLogicalPlan); // look for the next inlinejoin plan var newSubPlan = firstSubPlan(newLogicalPlan); if (newSubPlan == null) {// run the final "main" plan + LOGGER.debug("Executing final plan:\n{}", newLogicalPlan); var newPhysicalPlan = logicalPlanToPhysicalPlan(newLogicalPlan, request); runner.run(newPhysicalPlan, next.delegateFailureAndWrap((finalListener, finalResult) -> { completionInfoAccumulator.accumulate(finalResult.completionInfo());

I've added them

bpintea · 2025-06-26T14:11:34Z

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

@@ -217,8 +217,8 @@ public void executeOptimizedPlan(
        LogicalPlan optimizedPlan,
        ActionListener<Result> listener
    ) {
-        PhysicalPlan physicalPlan = logicalPlanToPhysicalPlan(optimizedPlan, request);
        if (explainMode) {


Nit: would it be worth extracting this case into an own method?

I've added a TODO to revisit this. explain in EsqlSession needs a second look, some things do not feel like they belong here.

bpintea · 2025-06-26T14:19:45Z

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

@@ -231,85 +231,88 @@ public void executeOptimizedPlan(
            values.add(List.of("coordinator", "optimizedPhysicalPlan", physicalPlanString));


It might be nice to be able to provide multiple rows of optimized logical plans, as each InlineJoin righthand side would get executed, since the outcome is predictable (a LocalRelation), but I guess we can leave a comment as a TODO (or an issue) for later (when/if EXPLAIN stabilizes).

Yes, this PR wants to be a solid base for further parallel branches of work on inlinestats. Modelling the InlineJoin properly is one of those follow up things.

bpintea · 2025-06-26T14:27:02Z

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

    }

-    private record PlanTuple(PhysicalPlan physical, LogicalPlan logical) {}
+    private record LogicalPlanTuple(LogicalPlan nonStubbedSubPlan, LogicalPlan originalSubPlan) {}


A logistical suggestion would be to isolate all the InlineJoin logic into its own class (could be nested), as there are a few methods here (plus this record) that are dedicated just for this feature.

bpintea · 2025-06-26T14:33:22Z

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

@@ -1001,3 +1108,171 @@ FROM hosts METADATA _index
  description:text |  host:keyword |   ip0:ip      | _index:keyword |   x:ip  | ip1:long | host_group:text | card:keyword
 alpha db server    |alpha          |127.0.0.1      |hosts           |127.0.0.1|1         |DB servers       |eth0
 ;
+
+doubleShadowing


I'd maybe add a similar test with multiple INLINESTATS and shaddowing with no groups and another one w/o shadowing, but still no groups.

The "no groups" part is the problematic one now (as in what I am still working on as part of the same PR that's still evolving).

I did give it a try and it worked fine. But haven't gone crazy with it, so more work is welcome, if needed.

I added the fix in the PruneColumns rule. It's about removing the inlinestats completely if its output is not needed. What happened in some queries was that the aggregation of the inlinestats was removed and the inlinejoin was left in a completely messed up state.

alex-spies

Second round - focused on the execution in EsqlSession this time.

Looks like we're going back in the direction of the initial approach to inline stats, where each phase had a full optimizer run. That's the right approach IMO.

I want to have another look next week to better understand the changes to the optimizer rules. But please go ahead and merge whenever you're happy (I see Bogdan already 👍'd the PR); if I find something I find important, I'll leave a comment after the merge.

alex-spies · 2025-06-27T06:34:41Z

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

    }

-    private record PlanTuple(PhysicalPlan physical, LogicalPlan logical) {}
+    private record LogicalPlanTuple(LogicalPlan nonStubbedSubPlan, LogicalPlan originalSubPlan) {}


nit: a comment explaining the purpose wouldn't hurt; it's not clear without reading more what the non stubbed plan is, and the name LogicalPlanTuple is also rather generic.

alex-spies · 2025-06-27T06:48:28Z

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

-                });
+                LogicalPlan newLogicalPlan = optimizedPlan.transformUp(
+                    InlineJoin.class,
+                    ij -> ij.right() == subPlans.originalSubPlan ? InlineJoin.inlineData(ij, resultWrapper) : ij


Nice! I think it's important we use object equality here - regular equality will not suffice because it ignores e.g. name ids.

Maybe worth a comment?

alex-spies · 2025-06-27T06:59:47Z

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

+                    InlineJoin.class,
+                    ij -> ij.right() == subPlans.originalSubPlan ? InlineJoin.inlineData(ij, resultWrapper) : ij
+                );
+                newLogicalPlan.setOptimized();


This is surprising. Shouldn't we re-optimize the plan now that we were able to replace the stub with an actual result?

After the stub was replaced, we can actually do more stuff, like push down limits (which before that would be wrong as it would have affected the stats).

If I understand correctly, this is something we might want to improve later, right? If so, let's leave a comment; maybe a TODO to make the intention clear.

Yeah, a TODO is right.

I had my doubts with this thing. I feel like there are things here that were left hanging (things do still seem they can be optimized further), but at this stage of the inlinestats progress, I think it's worth ignoring it. But TODO is needed, because it's something we need to think about a little.

Hmm, I thought this was sufficient. The approach basically gradually executes righthand sides of (inline) joins, always resulting in a LocalRelation. Ending up with a join with whatever was before on the left and this local relation on the right. Not sure if we can further optimise this (and haven't done it before - the LIMIT makes it past the InlineJoin into the lefthand side already, since InlineJoin preserves the rows count).
But a TODO can re-eval things later, 👍 .

Oh, we can further optimize it alright :)

The limit being pushed/copied down into the left hand side is a bug - that should only happen in subsequent passes. See my comment here.

Also, if the INLINESTATS has no BY clause, it can be turned into an EVAL with literals in subsequent phases, which can trigger more optimizations (like constant folding, filter pushdown, optimizing away checks against constant keyword fields). Some of this could probably be somehow hacked into the first optimization pass, but currently I think it's more natural (or at least easier) to just have another optimizer pass per query phase.

The limit being pushed/copied down into the left hand side is a bug - that should only happen in subsequent passes.

Actually, very true!

Also, if the INLINESTATS has no BY clause, it can be turned into an EVAL with literals in subsequent phases

I see. Yes, this could be done, but not with the current shape of the planning (i.e. rerunning the optimiser as it is now won't replan). But yes, you're right, this could still be evolved.

Aggregation. Move two methods from EsqlSession to InlineJoin. Address reviews Add more comments

…support_multi_inlinestats_logicalPlan_approach

alex-spies

Heya, all done now.

This is a nice advancement of INLINE STATS, let's go! I think there are a couple things to be looked at in follow ups, but this is fine to merge as-is IMO; we can continue iterating in follow-ups as the changes here do not seem to affect the code health of the non-INLINE STATS code paths.

Most notable follow-up items IMO:

Correctness of optimization rules w.r.t. stubs, esp. the limit pushdown.
More logical plan optimizer tests for PruneColumns and a good hard look at PruneColumns (maybe I'm misreading things though, see comments below)

alex-spies · 2025-06-30T12:59:55Z

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

@@ -60,7 +59,16 @@ public static LogicalPlan stubSource(UnaryPlan sourcePlan, LogicalPlan target) {
     * Replaces the stubbed source with the actual source.
     */
    public static LogicalPlan replaceStub(LogicalPlan source, LogicalPlan stubbed) {


nit: can we add a note that this will replace all stubs with the new source? In case of a plan with 2 stubs (dual inlinestats in the query), this method should normally be avoided to avoid chaos.

alex-spies · 2025-06-30T13:50:10Z

...in/esql/src/main/java/org/elasticsearch/xpack/esql/optimizer/rules/logical/PruneColumns.java

@@ -63,14 +67,18 @@ public LogicalPlan apply(LogicalPlan plan) {
                return p;
            }

+            if (p instanceof InlineJoin ij) {
+                inlineJoinRightOutput.addAll(ij.right().outputSet());


It would be nice to have a logical plan optimizer test that demonstrates the necessity for tracking the right outputs of inline stats.

Yes, this will be followups. Added TODO

alex-spies · 2025-06-30T13:57:27Z

...in/esql/src/main/java/org/elasticsearch/xpack/esql/optimizer/rules/logical/PruneColumns.java

@@ -111,7 +119,7 @@ public LogicalPlan apply(LogicalPlan plan) {
                    // Normally, pruning EsRelation has no effect because InsertFieldExtraction only extracts the required fields, anyway.
                    // However, InsertFieldExtraction can't be currently used in LOOKUP JOIN right index,
                    // it works differently as we extract all fields (other than the join key) that the EsRelation has.
-                    var remaining = removeUnused(esr.output(), used);
+                    var remaining = removeUnused(esr.output(), used, inlineJoinRightOutput);


This is odd. The right outputs should be computed from STATS, so the only attribute that could also occur here is a looked up field attr that's later used in the inlinestats' BY clause.

But this should also be contained in the InlineJoin's .references, i.e. should end up in the used set.

alex-spies · 2025-06-30T14:00:34Z

...in/esql/src/main/java/org/elasticsearch/xpack/esql/optimizer/rules/logical/PruneColumns.java

@@ -97,7 +105,7 @@ public LogicalPlan apply(LogicalPlan plan) {
                        }
                    }
                } else if (p instanceof Eval eval) {
-                    var remaining = removeUnused(eval.fields(), used);
+                    var remaining = removeUnused(eval.fields(), used, inlineJoinRightOutput);


Some aggs leave downstream EVALs, like AVG. Does this prevent them from being pruned, even if they're not needed downstream at all?

E.g. in INLINESTATS x = avg(y), a = count_distinct(field) BY z | EVAL x = z I'd expect that making the inline join's right hand side "unpruneable" prevents this rule from correctly pruning unused columns.

alex-spies · 2025-06-30T14:03:21Z

...in/esql/src/main/java/org/elasticsearch/xpack/esql/optimizer/rules/logical/PruneColumns.java

            // remember used
            boolean recheck;
            // analyze the unused items against dedicated 'producer' nodes such as Eval and Aggregate
            // perform a loop to retry checking if the current node is completely eliminated
            do {
                recheck = false;
                if (p instanceof Aggregate aggregate) {
-                    var remaining = removeUnused(aggregate.aggregates(), used);
+                    var remaining = removeUnused(aggregate.aggregates(), used, inlineJoinRightOutput);


This seems to protect the computed aggs in an inlinestats, no matter what?

I don't think this is correct long term; unused aggs in inlinestats need to be pruned, too. If the problematic case is when the inline stats ends up with 0 aggs, then I think we need an extra case that prunes the whole inline join. As inline joins preserve row count, this should be correct.

Can we at least leave a TODO? I think we'll need to revisit this and add a bunch of tests to make sure all works as intended.

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

alex-spies · 2025-06-30T16:19:49Z

...in/esql/src/main/java/org/elasticsearch/xpack/esql/optimizer/rules/logical/PruneColumns.java

+                        // TODO: InlineStats - prune ONLY the unused output columns from it? In other words, don't perform more aggs
+                        // if they will not be used anyway


alex-spies · 2025-06-30T16:21:57Z

...in/esql/src/main/java/org/elasticsearch/xpack/esql/optimizer/rules/logical/PruneColumns.java

@@ -104,6 +104,17 @@ public LogicalPlan apply(LogicalPlan plan) {
                            p = aggregate.with(aggregate.groupings(), remaining);
                        }
                    }
+                } else if (p instanceof InlineJoin ij) {// TODO: InlineStats - add unit tests for this IJ removal
+                    var remaining = removeUnused(ij.right().output(), used, inlineJoinRightOutput);


Aren't all of the attributes in ij.right().output() protected because they're contained in inlineJoinRightOutput?

alex-spies · 2025-06-30T16:26:40Z

...in/esql/src/main/java/org/elasticsearch/xpack/esql/optimizer/rules/logical/PruneColumns.java

@@ -39,15 +40,18 @@ public final class PruneColumns extends Rule<LogicalPlan, LogicalPlan> {
    public LogicalPlan apply(LogicalPlan plan) {
        // track used references
        var used = plan.outputSet().asBuilder();
+        // track inlinestats' own aggregation output (right-hand side of the join) so that any other plan on the left-hand side of the
+        // inline join won't have its columns pruned due to the lack of "visibility" into the right hand side output/Attributes
+        var inlineJoinRightOutput = new ArrayList<Attribute>();


I'm confused how this works in general. Expressions in the inline join's left side generally cannot depend on the stats output, resp. the inline join's right hand side. The dependency is converse - the IJ's right hand side depends on expressions in the left, because it will normally contain a stub.

Also, LOOKUP JOIN doesn't require handling the right hand side output attributes especially, which is suspicious.

Maybe I'm just not seeing it and need an example, though :)

The complication that I would expect: expressions on the left may get pruned because they don't appear in used. Without having tried, something like:

EVAL x = 2*y | INLINE STATS x = avg(x)

The first x is only required in the stats in the right hand side of the inline join, so we may optimize this away on accident if PruneColumns first descends into the left hand side and thus didn't yet add the x to the used attributes.

I didn't check if this actually happens, or if we maybe descend first into the right after all. Still, probably worth a test.

…support_multi_inlinestats_logicalPlan_approach

astefan · 2025-06-30T16:55:58Z

Asking some feedback from @nik9000 as well, especially related to CopyingLocalSupplier and whatever I am doing in there related to Blocks :-). I didn't change the ImmediateLocalSupplier to always behave like CopyingLocalSupplier because I wanted this behavior only for row commands where we know that blocks will always be released on a single node (the coordinator) whereas a LocalRelation might exist also on data nodes. I wanted to separate these two use cases completely.

…support_multi_inlinestats_logicalPlan_approach

nik9000

I have some opinions on the serialization change. Compared to the rest of the work they are super minor, but I think we should resolve my questions before merging.

...esql/src/main/java/org/elasticsearch/xpack/esql/plan/logical/local/CopyingLocalSupplier.java

nik9000 · 2025-07-02T17:03:37Z

...ck/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/plan/physical/LocalSourceExec.java

+        if (in.getTransportVersion().onOrAfter(TransportVersions.ESQL_LOCAL_RELATION_WITH_NEW_BLOCKS)) {
+            this.supplier = in.readNamedWriteable(LocalSupplier.class);
+        } else {
+            this.supplier = LocalSupplier.readFrom((PlanStreamInput) in);


I think it's important this method say that it's for the legacy serialization format somehow. Maybe just rename it.

Or, what about moving it to right here?

nik9000 · 2025-07-02T17:04:53Z

...n/esql/src/main/java/org/elasticsearch/xpack/esql/plan/logical/local/EmptyLocalSupplier.java

+
+    @Override
+    public void writeTo(StreamOutput out) throws IOException {
+        out.writeVInt(0);


I think this should probably be empty instead of compatible with the previous serialization.

nik9000 · 2025-07-02T17:09:03Z

...ck/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/plan/physical/LocalSourceExec.java

+        if (out.getTransportVersion().onOrAfter(TransportVersions.ESQL_LOCAL_RELATION_WITH_NEW_BLOCKS)) {
+            out.writeNamedWriteable(supplier);
+        } else {
+            supplier.writeTo(out);


This feels like it's subtle in a way that folks aren't likely to catch by reading it. I did because you told me to look here. But I don't trust myself to see it six months from now.

You made this work by forcing each variant to serialize in a way that's compatible with the original serialization. I think it'd be less surprising if instead you explicitly made an ImmediateSupplier or even just copied the old serialization code to here.

nik9000 · 2025-07-02T17:11:19Z

...n/esql/src/test/java/org/elasticsearch/xpack/esql/plan/logical/local/LocalSupplierTests.java

+                new PlanStreamOutput(output, null).writeNamedWriteable(instance);
+            } else {
+                instance.writeTo(new PlanStreamOutput(output, null));
+            }


It'd be more traditional to make this abstract and make a subclass for each LocalSupplier subclass. This works as is though.

…support_multi_inlinestats_logicalPlan_approach

nicpenning · 2025-07-08T14:37:43Z

Would Inline stats provide the result that this issue presents?

#128612

…lastic#128917) Part of elastic#124715 and similar to elastic#128476. Different from elastic#128476 in that it takes a "LogicalPlan" approach to running a sub-query, integrating its result back in the "main" LogicalPlan and continuing running the query.

Adopt a "LogicalPlan" approach to running multiple sub-queries,

0741bbb

coordinated from the EsqlSession.

astefan added >bug >enhancement :Analytics/ES|QL AKA ESQL v9.1.0 and removed >enhancement labels Jun 4, 2025

Update docs/changelog/128917.yaml

cd31f72

astefan added 8 commits June 4, 2025 18:56

checkstyle

811f5be

More tests un-Ignored and updates after update from main

567d600

Fix capability

f834ce7

TEMP

d3f2838

Adapt PruneColumns to have "visibility" into the right-hand side of

1e9c355

the inlinestats JOIN

Merge branch 'main' of https://github.com/elastic/elasticsearch into …

fa22575

…support_multi_inlinestats_logicalPlan_approach

More fixes and tests

377328c

Merge branch 'main' of https://github.com/elastic/elasticsearch into …

1c745c7

…support_multi_inlinestats_logicalPlan_approach

astefan commented Jun 12, 2025

View reviewed changes

astefan added 2 commits June 12, 2025 15:44

More deterministic test

cffa1d7

Merge branch 'main' of https://github.com/elastic/elasticsearch into …

0882cbb

…support_multi_inlinestats_logicalPlan_approach

astefan requested review from alex-spies and costin June 12, 2025 12:44

astefan marked this pull request as ready for review June 12, 2025 12:45

astefan added >enhancement and removed >bug labels Jun 12, 2025

elasticsearchmachine added the Team:Analytics Meta label for analytical engine team (ESQL/Aggs/Geo) label Jun 12, 2025

astefan added the v9.0.3 label Jun 12, 2025

Update docs/changelog/128917.yaml

e3b5c92

bpintea approved these changes Jun 26, 2025

View reviewed changes

elasticsearchmachine added v9.2.0 and removed v9.1.0 labels Jun 26, 2025

alex-spies reviewed Jun 27, 2025

View reviewed changes

astefan added 4 commits June 27, 2025 19:21

Add more tests and fix incorrect pruning of columns of the inlinestats'

17d5933

Aggregation. Move two methods from EsqlSession to InlineJoin. Address reviews Add more comments

Merge branch 'main' of https://github.com/elastic/elasticsearch into …

a88b8cf

…support_multi_inlinestats_logicalPlan_approach

More stuff

41d2119

Merge branch 'main' of https://github.com/elastic/elasticsearch into …

0cbfef9

…support_multi_inlinestats_logicalPlan_approach

alex-spies approved these changes Jun 30, 2025

View reviewed changes

astefan added 2 commits June 30, 2025 19:49

Tests fixes

bbe1a62

Merge branch 'main' of https://github.com/elastic/elasticsearch into …

f136b79

…support_multi_inlinestats_logicalPlan_approach

astefan requested a review from nik9000 June 30, 2025 16:53

astefan added 2 commits July 2, 2025 19:20

Further fixes and addressing reviews

0ba7a4a

Merge branch 'main' of https://github.com/elastic/elasticsearch into …

a2527ea

…support_multi_inlinestats_logicalPlan_approach

nik9000 requested changes Jul 2, 2025

View reviewed changes

astefan added 4 commits July 3, 2025 09:27

Merge branch 'main' of https://github.com/elastic/elasticsearch into …

c04806b

…support_multi_inlinestats_logicalPlan_approach

Rework the LocalSupplier serialization

5bb4e4f

Address reviews

8d05f3f

Merge branch 'main' of https://github.com/elastic/elasticsearch into …

f7268ad

…support_multi_inlinestats_logicalPlan_approach

nik9000 approved these changes Jul 7, 2025

View reviewed changes

astefan removed the v9.0.4 label Jul 7, 2025

Merge branch 'main' of https://github.com/elastic/elasticsearch into …

7ffaf8c

…support_multi_inlinestats_logicalPlan_approach

astefan removed the auto-backport Automatically create backport pull requests when merged label Jul 8, 2025

astefan changed the title ~~ESQL: Adopt a "LogicalPlan" approach to running multiple sub-queries (with INLINESTATS so far)~~ ESQL: INLINESTATS implementation with multiple LogicalPlan updates Jul 8, 2025

astefan added the auto-merge-without-approval Automatically merge pull request when CI checks pass (NB doesn't wait for reviews!) label Jul 8, 2025

elasticsearchmachine merged commit c9a4206 into elastic:main Jul 8, 2025
33 checks passed

astefan deleted the support_multi_inlinestats_logicalPlan_approach branch July 8, 2025 09:52

		@@ -231,85 +231,88 @@ public void executeOptimizedPlan(
		values.add(List.of("coordinator", "optimizedPhysicalPlan", physicalPlanString));

		// TODO: InlineStats - prune ONLY the unused output columns from it? In other words, don't perform more aggs
		// if they will not be used anyway

ESQL: INLINESTATS implementation with multiple LogicalPlan updates #128917

ESQL: INLINESTATS implementation with multiple LogicalPlan updates #128917

Uh oh!

Conversation

astefan commented Jun 4, 2025

Uh oh!

elasticsearchmachine commented Jun 4, 2025

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!

elasticsearchmachine commented Jun 12, 2025

Uh oh!

bpintea left a comment

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!

alex-spies left a comment

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!

alex-spies left a comment

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!

astefan Jun 30, 2025 • 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!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

astefan Jun 30, 2025 •

edited

Loading