-
Notifications
You must be signed in to change notification settings - Fork 25.4k
ST_EXTENT aggregation (#104659) #117451
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ST_EXTENT aggregation (#104659) #117451
Conversation
…ticsearch/xpack/esql/planner/AggregateMapper.java
...rc/main/java/org/elasticsearch/xpack/esql/expression/function/aggregate/SpatialStExtent.java
Outdated
Show resolved
Hide resolved
...rc/main/java/org/elasticsearch/xpack/esql/expression/function/aggregate/SpatialStExtent.java
Outdated
Show resolved
Hide resolved
...csearch/compute/aggregation/spatial/SpatialStExtentCartesianPointSourceValuesAggregator.java
Outdated
Show resolved
Hide resolved
...a/org/elasticsearch/compute/aggregation/spatial/SpatialStExtentCartesianShapeAggregator.java
Outdated
Show resolved
Hide resolved
...elasticsearch/compute/aggregation/spatial/SpatialStExtentGeoPointSourceValuesAggregator.java
Outdated
Show resolved
Hide resolved
...st/java/org/elasticsearch/xpack/esql/expression/function/aggregate/SpatialStExtentTests.java
Outdated
Show resolved
Hide resolved
...st/java/org/elasticsearch/xpack/esql/expression/function/aggregate/SpatialStExtentTests.java
Outdated
Show resolved
Hide resolved
x-pack/plugin/esql/src/test/java/org/elasticsearch/xpack/esql/expression/RectangleMatcher.java
Show resolved
Hide resolved
...ql/src/test/java/org/elasticsearch/xpack/esql/expression/WellKnownBinaryBytesRefMatcher.java
Show resolved
Hide resolved
* Also note that the type converting function is removed when it does not actually convert the type, | ||
* ensuring that ReferenceAttributes are not created for the same field, and the optimization can still work. | ||
*/ | ||
public void testSpatialTypesAndStatsExtentUseDocValues() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps a test that has both centroid and extent aggregations?
…rch into feature/st_extent
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. I think some PhysicalPlanOptimizerTests over shapes would be good, but that can be done in the next PR where we do shape optimization.
💔 Backport failed
You can use sqren/backport to manually backport by running |
This PR adds support for ST_EXTENT_AGG aggregation, i.e., computing a bounding box over a set of points/shapes (Cartesian or geo). Note the difference between this aggregation and the already implemented scalar function ST_EXTENT. This isn't a very efficient implementation, and future PRs will attempt to read these extents directly from the doc values. We currently always use longitude wrapping, i.e., we may wrap around the dateline for a smaller bounding box. Future PRs will let the user control this behavior. Fixes elastic#104659.
This PR adds support for ST_EXTENT_AGG aggregation, i.e., computing a bounding box over a set of points/shapes (Cartesian or geo). Note the difference between this aggregation and the already implemented scalar function ST_EXTENT. This isn't a very efficient implementation, and future PRs will attempt to read these extents directly from the doc values. We currently always use longitude wrapping, i.e., we may wrap around the dateline for a smaller bounding box. Future PRs will let the user control this behavior. Fixes elastic#104659.
This PR adds support for ST_EXTENT_AGG aggregation, i.e., computing a bounding box over a set of points/shapes (Cartesian or geo). Note the difference between this aggregation and the already implemented scalar function ST_EXTENT. This isn't a very efficient implementation, and future PRs will attempt to read these extents directly from the doc values. We currently always use longitude wrapping, i.e., we may wrap around the dateline for a smaller bounding box. Future PRs will let the user control this behavior. Fixes elastic#104659.
This PR adds support for ST_EXTENT_AGG aggregation, i.e., computing a bounding box over a set of points/shapes (Cartesian or geo). Note the difference between this aggregation and the already implemented scalar function ST_EXTENT. This isn't a very efficient implementation, and future PRs will attempt to read these extents directly from the doc values. We currently always use longitude wrapping, i.e., we may wrap around the dateline for a smaller bounding box. Future PRs will let the user control this behavior. Fixes elastic#104659.
This PR adds support for ST_EXTENT_AGG aggregation, i.e., computing a bounding box over a set of points/shapes (Cartesian or geo). Note the difference between this aggregation and the already implemented scalar function ST_EXTENT. This isn't a very efficient implementation, and future PRs will attempt to read these extents directly from the doc values. We currently always use longitude wrapping, i.e., we may wrap around the dateline for a smaller bounding box. Future PRs will let the user control this behavior. Fixes #104659.
Support
ST_EXTENT
aggregation (Issue #104659)This PR adds support for
ST_EXTENT
aggregation, i.e., computing a bounding box over a set of points/shapes (Cartesian or geo). (Note the difference between this aggregation and the already implemented *scalar *functionST_EXTENT
).Fixes #104659