This is a follow-up to an issue discovered in #141082. It seems that the ExchangeExec in ComputeService.reductionPlan is created using the old output attributes rather than the new one, and because the Exchange wrapping happens after the local optimization, we don't have a consistency check that verifies this isn't happening.
This is technically fine, since in reality the exchanges just pipe whatever pages they get, ignoring their declared output, but it is messy and should be fixed. In addition, we should add a consistency check (that only runs during tests) to ensure this doesn't happen again.
Possible lead:
|
ExchangeSinkExec updatedDataPlan = originalPlan.replaceChild(updatedFragmentExec); |
though there may be other places.
This is a follow-up to an issue discovered in #141082. It seems that the
ExchangeExecinComputeService.reductionPlanis created using the old output attributes rather than the new one, and because the Exchange wrapping happens after the local optimization, we don't have a consistency check that verifies this isn't happening.This is technically fine, since in reality the exchanges just pipe whatever pages they get, ignoring their declared output, but it is messy and should be fixed. In addition, we should add a consistency check (that only runs during tests) to ensure this doesn't happen again.
Possible lead:
elasticsearch/x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/plugin/LateMaterializationPlanner.java
Line 131 in abce951
though there may be other places.