Skip to content

ST_EXTENT aggregation (#104659)#117451

Merged
GalLalouche merged 58 commits intoelastic:mainfrom
GalLalouche:feature/st_extent
Dec 13, 2024
Merged

ST_EXTENT aggregation (#104659)#117451
GalLalouche merged 58 commits intoelastic:mainfrom
GalLalouche:feature/st_extent

Conversation

@GalLalouche
Copy link
Contributor

@GalLalouche GalLalouche commented Nov 25, 2024 •
edited
Loading

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 *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
@elasticsearchmachine elasticsearchmachine added needs:triage Requires assignment of a team area label v9.0.0 labels Nov 25, 2024
@GalLalouche GalLalouche marked this pull request as draft November 25, 2024 09:57
@GalLalouche GalLalouche removed needs:triage Requires assignment of a team area label v9.0.0 labels Nov 25, 2024
@GalLalouche GalLalouche added >feature :Analytics/Geo Indexing, search aggregations of geo points and shapes Team:Analytics Meta label for analytical engine team (ESQL/Aggs/Geo) auto-backport Automatically create backport pull requests when merged :Analytics/ES|QL AKA ESQL labels Dec 2, 2024
craigtaverner
craigtaverner requested changes Dec 12, 2024
View reviewed changes
...in/esql/src/test/java/org/elasticsearch/xpack/esql/optimizer/PhysicalPlanOptimizerTests.java
* 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() {
Copy link
Contributor

@craigtaverner craigtaverner Dec 12, 2024

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?
craigtaverner
craigtaverner approved these changes Dec 12, 2024
View reviewed changes
Copy link
Contributor

@craigtaverner craigtaverner left a 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.
@GalLalouche GalLalouche merged commit 2be4cd9 into elastic:main Dec 13, 2024
@elasticsearchmachine
Copy link
Collaborator

elasticsearchmachine commented Dec 13, 2024

💔 Backport failed

Status Branch Result
❌ 8.x Commit could not be cherrypicked due to conflicts

You can use sqren/backport to manually backport by running backport --upstream elastic/elasticsearch --pr 117451
GalLalouche added a commit to GalLalouche/elasticsearch that referenced this pull request Dec 17, 2024
@GalLalouche
ESQL: Support ST_EXTENT_AGG (elastic#117451)
4e644ce 
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.
@GalLalouche GalLalouche mentioned this pull request Dec 17, 2024
Merged
GalLalouche added a commit to GalLalouche/elasticsearch that referenced this pull request Dec 17, 2024
@GalLalouche
ESQL: Support ST_EXTENT_AGG (elastic#117451)
5bd6b61 
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.
GalLalouche added a commit to GalLalouche/elasticsearch that referenced this pull request Dec 17, 2024
@GalLalouche
ESQL: Support ST_EXTENT_AGG (elastic#117451)
9efa791 
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.
GalLalouche added a commit to GalLalouche/elasticsearch that referenced this pull request Dec 17, 2024
@GalLalouche
ESQL: Support ST_EXTENT_AGG (elastic#117451)
2029c26 
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.
elasticsearchmachine pushed a commit that referenced this pull request Dec 17, 2024
@GalLalouche
ESQL: Support ST_EXTENT_AGG (#117451) (#118829)
905f9f4 
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

:Analytics/ES|QL AKA ESQL :Analytics/Geo Indexing, search aggregations of geo points and shapes auto-backport Automatically create backport pull requests when merged backport pending >feature Team:Analytics Meta label for analytical engine team (ESQL/Aggs/Geo) v8.18.0 v9.0.0

4 participants

@GalLalouche @elasticsearchmachine @craigtaverner @astefan